Hallöle,

mit Delphi kann ich ja wunderbar SQL-Clients zusammenbauen, die dann die verschiedensten SQL-Server ansprechen können. Soviel ist klar.
Mir ist irgendwo auch klar, das ich mit Delphi sicherlich auch einen SQL-Server basteln kann. Ich hab bloß leider absolut keinen Ansatz, denn bezüglich Server-Techniken sagen mir die Komponenten alle nicht wirklich viel, und auch die Delphi-Hilfe hat zum Thema SQL-Server nicht viel in petto.

Daher also meine Fragen, ganz konkret:
Kann ich mit Delphi (7) ohne weiteres oben beschriebenes realisieren?

Wo gibt es für sowas gute Tutorials? Wenn ich nämlich (z.B.) nach Delphi SQL-Server Tutorial google, krieg ich nur irgendwelche Fachliteratur, meist zum Thema SQL-Server von Drittanbietern, aber keine Anleitung zum selber coden von SQL-Servern unter Delphi!


mfg
kiwicht

//EDIT
bevor wieder die ersten Kommentare kommen , von wegen nimm doch Interbase oder MySQL etc: Geht nicht, ich "brauch" n selbst programmierten Server, weil ich noch alte DBaseIII+-DBs benutze, und die sich nach meinem Kentnisstand nicht mit oben genannten DB-Servern weiternutzen lassen!

Dein Problem ist nicht, wie kann ich einen SQL-Server selber proggen, sondern Du solltest eher nach dem Stichwort Three-Tier-Anwendung (Client-Server) schauen. Du machst eine Server-Applikation, die auf die DBase-Daten zugreift und über die andere Clients darauf zugreifen. Das ist aber net ganz einfach, kann ich Dir sagen, hab mich auch ein bisschen damit beschäftigt, und es dann gelassen (vorerst).

Trotzdem muss ich Dir sagen, was Du nicht gerne hörst: Nimm nen richtigen SQL-Server, da gibts son nettes Tool, das nennt sich DataPump, damit kannst Du Daten zwischen Datenbanken verschiedenster Art transeferieren.

Gruß

Zitat:

Trotzdem muss ich Dir sagen, was Du nicht gerne hörst: Nimm nen richtigen SQL-Server, da gibts son nettes Tool, das nennt sich DataPump, damit kannst Du Daten zwischen Datenbanken verschiedenster Art transeferieren.

Hab ich auch schon mal von gehört, aber das geht nicht, da die Datenbanken einerseits immer noch von DOS-Programmen genutzt werden, da kann ich nicht einfach die Datenbank-Formate ändern...

Ich werd wohl in den sauren Apfel beissen müssen, und dieses ominöse Thier-Bla genauer unter die Lupe nehmen..

thx

Gut, da bleibt Dir wohl keine andere Möglichkeit. Da musste halt Dein eigenes Protokoll für die Datenübertragung schreibe.
Aber ich geb Dir nen Tipp: Ich würde XML für die Übertragung verwenden, da musste dann net alles à la CORBA usw machen, sondern kannste ne einfache TCP-Verbindung verwenden und damit komplette Befehle und Datensätze übetragen...

guti, xml klingt ja schonmal ganz vielversprechend.. und wie siehts Delphi-seitig aus? Gibts da Extra-Komponenten, oder nutz ich die Standard-Kommunikation von Delphi?

Und was ist mit Tutorial, ich würd ja sonst ewig brauchen...

mfg & big thx

kiwicht hat folgendes geschrieben:

bevor wieder die ersten Kommentare kommen , von wegen nimm doch Interbase oder MySQL etc: Geht nicht, ich "brauch" n selbst programmierten Server, weil ich noch alte DBaseIII+-DBs benutze, und die sich nach meinem Kentnisstand nicht mit oben genannten DB-Servern weiternutzen lassen!

Hast Du Dir mal überlegt, warum solche Kommentare kommen, wenn Du schon ahnst, daß sie kommen Weil sie berechtigt sind. Bis Du einen eigenen DB-Server zusammengebaut hast, bist Du kurz vorm Rentenalter.

Warum übernimmst Du die alten Daten nicht in eine IB-Datenbank ?? Dann wäre die Birne wohl geschält. Vor allem wärst Du schneller fertig mit dem Mist. Mir gelingt es mittlerweile ein Programm für eine Table in ca. 1-2 St. zu schreiben, welches die Table anlegt, alle alten Daten übernimmt usw.

Für die erste habe ich allerdings eine Woche gebraucht.

@UGrohne : habe hier ein Programm gebastelt, das XML-Daten in eine Interbase übernimmt. Nur wo besteht der Zusammenhang mit der Geschichte hier

Zitat:

Hast Du Dir mal überlegt, warum solche Kommentare kommen, wenn Du schon ahnst, daß sie kommen Weil sie berechtigt sind. Bis Du einen eigenen DB-Server zusammengebaut hast, bist Du kurz vorm Rentenalter. @UGrohne : habe hier ein Programm gebastelt, das XML-Daten in eine Interbase übernimmt. Nur wo besteht der Zusammenhang mit der Geschichte hier

Ähm, ja, wir haben ja jetzt schon darüber diskutiert.... wer lesen kann, hat klar nen Vorteil, gell
Es gibt ja noch alte Progs, die diese DB benützen und die kann er nicht verändern, laufen ja teils noch auf DOS.

XML hab ich im Zusammenhang mit Three-Tier-Anwendung gesagt. D.h. er hat ne Server-App, die auf die DB zugreift. DIe stellt z.B. einen TCP-Server. DIe Clients connecten zu dieser über eine TCP-Verbindung. Da aber die einfachste Kommunikation dazwischen Zeichenfolgen sind, schlage ich vor, um z.B. auch Records oder eben Datensätze zu übermitteln, das ganze in XML zu packen und von der Gegenstelle parsen zu lassen. Is die einfachste Möglichkeit, viele Informationen auf einen Rutsch zu verschicken, oder ?

Gruß[/quote]

Zitat:

Warum übernimmst Du die alten Daten nicht in eine IB-Datenbank ??

Also, nochmal im Klartext:
Es gibt hier einige verschiedene Datenbanken, alle vom selben vorsintflutigen Typ DBaseIII+.
Einige dieser DB´s werden immer noch mit alten DOS-Programmen genutzt, daran lässt sich auch nichts ändern.
Andererseits konnte ich einige dieser DOS-Programme schon erfolgreich zu Windows portieren, aber halt nicht alle.
Die DOS-Prog´s greifen auf ihre Art und Weise auf den Server zu, meine W32-Prog´s erledigen sämtliche SQL-Anweisungen Client-Seitig.
Das dauert bei einigen Rechner, da diese schon etwas älter sind, natürlich erheblich lange, weshalb ich jetzt eine Möglichkeit suche, die alten DBaseIII+ Dateien auf einem Server zu verwalten.
MySQL und Co. sind zwar super SQL-Server, die alles können, aber sie können nicht mit meinen DBaseIII+-Datenbanken arbeiten, deshalb muss ein klitzkleines Server-Proggi her, was nicht viel mehr beherrschen muss als SQL-Anweisungen auszuführen und die Ergebnismenge zurückzuschicken.

Die XML-Geschichte hört sich ja schon ma ganz vielversprechend an, nur bräucht ich da n Tutor oder vergleichbares, damit ich mir nicht die Delphi-Doku´s, da in englisch, reinquälen muss.

UGrohne hat das soweit ja schonma richtig erkannt..
Den Weg zum Ziel, den kenn ich also, aber wie muss ich diesen Weg beschreiten??

danke auf jeden Fall erstmal für eure Anteilnahme

mfg
kiwicht

Hallo,

kiwicht hat folgendes geschrieben:

Die XML-Geschichte hört sich ja schon ma ganz vielversprechend an, nur bräucht ich da n Tutor oder vergleichbares, damit ich mir nicht die Delphi-Doku´s, da in englisch, reinquälen muss.

vieleicht ist das ja ein guter Anfang.

Gruß
Klabautermann

Danke Klabautermann, hab das Tut eben durch gelesen, und schon gleich meine erste XML-Anwendung geschrieben...

Und bezogen auf mein Problem:

Meint Client packt jetzt also seine SQL-Anweisung in XML-Text, und sendet diesen an meinem Server.
Der Server liest die SQL-Anweisung aus, führt sie aus, erhält die Ergebnismenge zurück und packt diese sogleich wieder in XML-Text, um damit dem Client zu antworten.
Der Client kann aus diesem XML-Text die Ergebnismenge auslesen, von mir aus pro Node ein Datenbankfeld, und in seinen DBControls anzeigen.

Hab ich das richtig verstanden? Wenn ja, dann klingt das alles sehr einfach, bis auf die Sache mit dem Senden und Empfangen. Aber da muss ich wohl warten bis Hagbard Celine zu dem Thema kommt....

erstma herzlichsten Dank

mfg
kiwicht

Hallo,

ja so inetwa kommt das hin. Die schwierigkeit ist, dass du Anfragen aus meheren Quellen (von Mehreren Clients) bearbeiten und die ergebnisse wieder an den richtigen zurückschicken musst.

Auf Clientseite musst du das ganze dann wieder zu einem tDataset umwandeln (z.B. eine Memory Table) wenn du mit den DBKompos Arbeiten willst.
DBExpress kann übrigens direckt mit XML-Dateien arbeiten, das gibt es aber erst seit D6 und ich weiß nicht ob man die XML Daten auch aus dem Speicher (Stream) übernehmen kann.

Gruß
Klabautermann

Ich glaub die Sache mit den verschiedenen Clients ist das allerkleinste Problem.
Wenn einfach jeder Client eine eigene ID (bzw. IP) hat, die er in dem XML-Dokument mitschickt, weiß der Server ja wohin die Antwort geht.
Genauso kann im XML-Dokument ja auch eine ID entsprechend einer Datenbank gespeichert werden, um mit mehreren DB´s zu arbeiten. Das ist wie gesagt alles nicht weiter wild.

Priorität hat jetzt erstmal die TCP-Verbindung ansich, mit der werd ich mich wohl erstma anfreinden müssen...

so long...
kiwicht

Nochma n Nachtrag:

Was wäre denn, oder, ist es auch möglich, wenn ich mit FTP arbeite:
Also so:
Client schickt SELECT an Server, Server berechnet Ergebnis, und schickt dieses per FTP zum Client, der damit seine Datenbank nach seinen Wünschen gefiltert, erhält!

Was sagt ihr dazu? Möglich? Dumm? Zu langsam? Neee?

kiwicht hat folgendes geschrieben:

Was sagt ihr dazu? Möglich? Dumm? Zu langsam? Neee?

Ganz klares: Neeeeee! Aus zwei Gründen:

1. Musst Du dann für jede Abfrage eine neue Datenbank erzeugen->Temporäre Datei->Speicherplatzverbrauch->Unhandlichkeit->Viel Programmieraufwand
2. Speicherplatz: Der muss für jede Abfrage eine komplette DB-Datei ziehen? Bisschen viel, oder? Er hat schließlich alle Systemtabellen komplett mit drin, + Indizes.

Absolut sinnloser Aufwand, meines Erachtens. Halt Dich lieber an TCP, is wesentlich einfacher.... im Endeffekt und effizienter.

Zitat:

1. Musst Du dann für jede Abfrage eine neue Datenbank erzeugen->Temporäre Datei->Speicherplatzverbrauch->Unhandlichkeit->Viel Programmieraufwand

Speicherplatzverbrauch? Ich glaub das kann ich vernachlässigen... wenn die DB 5 MB groß ist, und das ist schon ne Menge, und gleichzeitig 10 User darauf zugreifen (und auch das ist schon viel) entstehen 50 MB temporäre Dateien,und das kann man glaub ich verkraften.
50 MB entstehen auch nur dann, wenn die zurück gegebene Menge jedesmal die komplette Datenbank beinhaltet, meistens werden die Anwender aber als Ergebniss eine Menge von vielleicht höchstens der Hälfte zurück erhalten, was das den verbrauchten Platz natürlich noch mehr verringert.

Zitat:

2. Speicherplatz: Der muss für jede Abfrage eine komplette DB-Datei ziehen? Bisschen viel, oder? Er hat schließlich alle Systemtabellen komplett mit drin, + Indizes.

Bei einem 100MBit-LAN dürften 5 MB wohl nicht wirklich lange dauern, vielleicht 2 Sekunden, mehr nicht. Verglichen mit der Zeit, die manche Uralt-Clients brauchen, um die Ergebnis-Menge selber zu berechnen, nämlich teilweise 5-10 Sekunden... auch kein Thema.

Der Vorteil ist doch auch, das sich größere Dateien über das FTP leichter übertragn lassen, als wenn ich diese über TCP verschicke, oder irr ich?

Klärt mich auf, ich lass mich gerne eines besseren belehren!

Ja, aber du brauchst ja noch ne Dateiverwaltung, damit mehrere Clients gleichzeitig abfragen erstellen können. Dann musst Du ja immer ne neue DB-Datei erzeugen und glaub mir, das dauert ein paar Sekunden. Da ist es doch viel effizienter, die Datensätze in XML zu packen (das geht auch mit einem ClientDataSet) und diese dann einfach zu verschicken, is viiiiel schneller und einfacher.... schließlich musst du sonst jedes Mal Dein DB-Script neu einpflegen, damit die temporären Dateien erzeugt werden können. Und eine normale LEERE Datenbank hat unter Interbase z.B. schon 500kB, wegen den ganzen Systemtabellen.
Aber wenn Du's unbedingt machen willst bitte, aber zukunftsweisend is das net *g* und beim anderen kannst du wohl eher was lernen, was du spöter auch noch brauchen kannst..

Gruß

hm, na gut, geb mich geschlagen, bin überzeugt, ich hab mich eben vor dem ganzen neuen Kram gescheut, aber da muss ich dann wohl durch....

trotzdem danke
mfg
kiwicht

*g* Man lernt nie aus.... aber glaub mir, es bringt dir was und so schwer is die sache mit XML ja nicht.... dachte es auch erst am anfang und in zukunft is das bei mir immer drin, wenn ich größere sachen austauschen muss.

die XML-geschichte hab ich ja mittlerweile gerafft, aber mir grauts vor der ganzen TCP-Kommunikation...
habs gerade mal geschafft "PING" hin und "PONG" zurück
zu schicken, und jetzt kommt halt der große XML-Transport...

naja, kommt Zeit, kommt KnowHow

mfg