Zitat von mm1256:

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

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

Zitat von mm1256:

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

Wieso transaktionsfähig?

Zitat von Mavarik:

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 von Mavarik:

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

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

Zitat von p80286:

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.

Zitat von Mavarik:

- 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.

Zitat von mm1256:

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

Ja, denn die Software nutze ich "selber".

Zitat von Dejan Vu:

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

zusammenfalten · markieren

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.