Thread getriebene SQLite Zwischenschicht?!

[Mavarik]

@Dejan Vu & @Sir Rufo

Ich macht Euch viel zu viele Gedanken. Das Funktioniert doch schon alles...

OnBeforeOpen
- Get New & Lock
OnAfterClose
- Post New & Unlock

Leider habe ich auf ein eindeutiges ID (Autoinc) bei Design gesetzt... War ein Fehler! Aber darum geht es ja gar nicht.

Nur als kleinen Hintergrund:
Das Ganze ist aus der ENZ-BTreeIsam aus DOS-Zeiten noch. (Ja ich bin alt...) Und da wurde halt eine SeekNr genommen.
Dann habe ich die Routinen für Windows 95 und Delphi 3 auf Windows umgestellt.
Mit Delphi 4 (glaube ich) habe ich eigene Datenbank Komponenten geschrieben die auf diese Datenbank aufsetzen.
Mit Delphi 7 habe ich das ganze (ohne eine Zeile am Hauptprogramm zu ändern) auf MySQL umgestellt)! Und aus der SeekNr wurde das ID.
Mit Delphi 2007 dann den Serverübergreifenden Sync (auch wieder ohne eine Zeile am Hauptprogramm zu ändern)!
Jetzt stehen halt mal wieder Verbesserungen an und ein Wechsel zu FireDac um die Fehler der alten MySQL Komponenten los zu werden.

Da ich FireDac entwas "unübersichtlich" finden... Meine Frage ob ich mit ner MemTable die im Hintergrund auf den Server das Update durchführt, auf dem richtigen Weg bin oder lieber etwas anderes nehmen soll.

An eine Service-Anwendung hatte ich auch schon gedacht... Läßt sich nur immer so schlecht debuggen.

Vielleicht auch lieber einfach per TCP/IP in eine App auf dem lokalen Server einloggen die Daten "nativ" also binär übertragen und auf dem lokalen Server erst in SQL umwandeln. ALLE Daten liegen sowieso in Records vor. Eine TCP/IP Übertragung der nativen Daten, wäre warscheinlich sowieso um den Faktor 10x bis 100x schneller... Und dann kann die "Serverapp" losorgeln.

Oder und daher der Title "Thread" die Umwandlung lokal innerhalb der Software und dann auf den Server. Die Software läuft sowieso fast 24/7.

Grüsse Mavarik

[mm1256]

[OffTopic]

Zitat:

Zitat von Mavarik (Beitrag 1278751)

Das Ganze ist aus der ENZ-BTreeIsam aus DOS-Zeiten noch. (Ja ich bin alt...) . . .

Nicht nur du :) aber, Mann o Mann, das war noch ne Datenbank.

[/OffTopic]

Zum Thema bzw. zur Frage: MemTable würde ich persönlich nicht bevorzugen, es sei denn, du kannst das in Transaktionen verpacken. Da wäre die TCP/IP-Variante schneller, und wahrscheinlich auch sicherer, weil transaktionsfähig 8-)

Gruss vom MM Baujahr 56

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1278779)

Nicht nur du :) aber, Mann o Mann, das war noch ne Datenbank.

Funktionierte, kaum erkennbare Fehler... schnell... jojojo

Zitat:

Zitat von mm1256 (Beitrag 1278779)

Zum Thema bzw. zur Frage: MemTable würde ich persönlich nicht bevorzugen, es sei denn, du kannst das in Transaktionen verpacken. Da wäre die TCP/IP-Variante schneller, und wahrscheinlich auch sicherer, weil transaktionsfähig 8-)

Wieso transaktionsfähig?

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1278676)

...
Leider:
a.) passiert es immer wieder, dass während dem Datentransfer die Verbindung zum Server abraucht.
b.) ist ggf. die Wartezeit nach einem Open der Datenbank recht lange, wenn die andere Seite viele Daten eingefügt hat.
...

Zitat:

Zitat von Mavarik (Beitrag 1278751)

@Dejan Vu & @Sir Rufo
Ihr macht Euch viel zu viele Gedanken. Das Funktioniert doch schon alles...

OnBeforeOpen
- Get New & Lock
OnAfterClose
- Post New & Unlock

Also wenn alles funktioniert, was willst Du dann? Ich denke, es geht gerade so *nicht*. Da kann man dann schon mal nachdenken. Aber da alles funktioniert, ist ja auch alles klar und es gibt keine Probleme.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1278789)

Also wenn alles funktioniert, was willst Du dann? Ich denke, es geht gerade so *nicht*. Da kann man dann schon mal nachdenken. Aber da alles funktioniert, ist ja auch alles klar und es gibt keine Probleme.

- wie gesagt. Es gibt Abbrüche und ich will die MySQL Componenten wechseln.
- und modernisieren.

Nur weil etwas funktioniert bedeutet es doch nicht, dass es nicht noch besser funktionieren kann...
Aber meine Frage war ja Firedac Memtable ja oder etwas anderes.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1278789)

Also wenn alles funktioniert, was willst Du dann? Ich denke, es geht gerade so *nicht*. Da kann man dann schon mal nachdenken. Aber da alles funktioniert, ist ja auch alles klar und es gibt keine Probleme.

Mann, es läuft nicht optimal und er wehrt sich alles auf den Müll zu schmeißen, nur um die Superduperdistributetobjectorienteddatastoragelösu ng zu installieren, bei der in 3 Jahren jeder die Schulter zuckt und fragt was das alte Zeug soll.

Gruß
K-H

[Mavarik]

Zitat:

Zitat von p80286 (Beitrag 1278800)

...und er wehrt sich alles auf den Müll zu schmeißen...

Genau... 1 Mio. Zeilen Source die fest mit der ENZ ISAM verknüpft sind, baut man nicht mal eben um auf Firedac...

Besonders nicht, wenn man dafür nicht bezahlt wird...

Mavarik :stupid:

[mm1256]

Zitat:

Zitat von Mavarik (Beitrag 1278784)

Wieso transaktionsfähig?

na ja, was passiert denn wenn während eines Schreibvorganges ein Problem auftritt (PC bzw. OS bleibt hängen, Stromausfall...). Dann hängt die MemTable "irgendwo"....und du hast ein Problem.

Zitat:

Zitat von Mavarik

Besonders nicht, wenn man dafür nicht bezahlt wird...

Macht es dann überhaupt Sinn sich über zeitaufwändige Optimierungen Gedanken zu machen?

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1278800)

Mann, es läuft nicht optimal und er wehrt sich alles auf den Müll zu schmeißen, nur um die Superduperdistributetobjectorienteddatastoragelösu ng zu installieren, bei der in 3 Jahren jeder die Schulter zuckt und fragt was das alte Zeug soll.

Wo steht denn, 'alles auf den Müll zu schmeißen' sei eine Lösung?
Wenn man die Wartezeiten während des Abgleiches nicht will, dann kann/muss man das im Hintergrund machen. Und wenn man das im Hintergrund macht, muss man eben noch 1-2 Dinge beachten. Hört sich jetzt nicht nach einer Lösung an, bei der man alles auf den Müll schmeißen muss. Und eine "objektkorientierte Datastoragelösung" muss das auch nicht werden, weil man das auch in VB oder C programmieren kann. :stupid:

Zitat:

Zitat von Mavarik (Beitrag 1278794)

- wie gesagt. Es gibt Abbrüche und ich will die MySQL Componenten wechseln.
- und modernisieren.
...

Und die Wartezeiten bei vielen Änderungen vermeiden?

Wenn die Datenbankzugriffe nicht gekapselt sind, wird das allerdings eine größere Operation.

Du wirst schon eine pragmatische Lösung finden. Ich würde -wenn überhaupt- zuerst die DB-Komponenten austauschen und dabei kapseln. Wenn alle DB-Zugriffe abstrahiert sind (d.h. in Klassen gekapselt) kann man die Reconcile-Logik einbauen, d.h.: Daten werden lokal und global verändert, wer gewinnt? Muss man aber nicht.

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1278827)

Macht es dann überhaupt Sinn sich über zeitaufwändige Optimierungen Gedanken zu machen?

Ja, denn die Software nutze ich "selber".

Zitat:

Zitat von Dejan Vu (Beitrag 1278867)

Wenn die Datenbankzugriffe nicht gekapselt sind, wird das allerdings eine größere Operation.

So gesehen sind die "eigentlich" zu 100% gekapselt.
Beispiel:

Meine TISAMEdit Komponente hat eine Verknüpfung zu einer TISAMBase Komponente und kann den da gespeicherten Record lesen und schreiben...

Die Verarbeitung ist ganz normal ENZ :stupid:

Delphi-Quellcode:

Adressen : TISAMBase; 

begin
  Adressen.BTInitIsam;
  Adressen.Open := true;
  RetKey := Adressen.Findkey(KeyNr,SeekNr,SearchKey);
  if (RetKey = SearchKey) and (Adresse.ISAMError = ISAMOK) then
    begin
      Adressen.GetRec(SeekNr);
      Adressen.Edit;
      ...
      Adressen.PutRec(SeekNr);
      Adressen.AddKeys;
    end;
   Adressen.Open := false;
   Adressen.BTDeInitIsam;
end;

Naja und die Findkey, GetRec, Edit, Put, AddKeys usw. werden halt in der ehemaligen ISAM umgesetzt in SQL.

Mavarik

PS.: Aber die eigentlich Frage war immer noch nach der Richtigen FireDac Komponente für die Zwischenschicht.