Die Idee von Sir Rufo würde bedeuten, irgendwie irgendwo ein zweites Programm zu starten. Fände ich auch naheliegend, wobei dann eventuell noch kleinere Synchronisationsprobleme gelöst werden müssen (Datensatz wird aktualisiert, während er in Bearbeitung ist).

Die Idee mit dem Thread ist dann verständlich, wenn kein zweites Programm laufen soll. Dann ist dieser 'Service' eben ein Thread.

Zitat von Dejan Vu:

Die Idee von Sir Rufo würde bedeuten, irgendwie irgendwo ein zweites Programm zu starten. Fände ich auch naheliegend, wobei dann eventuell noch kleinere Synchronisationsprobleme gelöst werden müssen (Datensatz wird aktualisiert, während er in Bearbeitung ist).

Die Idee mit dem Thread ist dann verständlich, wenn kein zweites Programm laufen soll. Dann ist dieser 'Service' eben ein Thread.

Das Sync-Problem ist doch schon gelöst (so wie es jetzt auch schon ist):

AKTUELL:

• Anwendung startet
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
  • Daten vom Hauptserver
• Anwendung endet
  • Daten zum Hauptserver
  • Datenbank freigeben (0)

VORSCHLAG:

• Anwendung startet
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
• Anwendung endet
  • Datenbank freigeben (2)
• Service Abgleich
  • Warten auf freie Datenbank (2)
  • Datenbank sperren (1)
  • Daten zum Hauptserver
  • Daten vom Hauptserver
  • Datenbank freigeben (0)
• Service Abgleich
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
  • Daten vom Hauptserver
  • Datenbank freigeben (0)

Alles was es da an Sync-Problemen aktuell gibt, werden mit diesem Ansatz nicht gelöst, ist aber auch nicht Gegenstand der Frage gewesen

Was ich nicht verstehe "Datenbank sperren" ist doch ein unnötiger Flaschenhals Datensatz/sätze wäre mir einleuchtender.

Gruß
K-H

Genau, denn damit wird die lange Wartezeit bei vielen Änderungen nicht vermieden. Und wenn man den Datensatz sperrt, dann so kurz wie möglich und dann gibt es wieder 'race conditions', die gelöst werden müssen. Aber das ist ja alles keine Hexerei. Wenn z.B. ein Datensatz gerade zum Ändern gesperrt ist, kann er nicht aktualisiert werden. Dann würde eine Aktualisierung u.U. einen Reconcilekonflikt auflösen (Feld A wurde lokal und global verändert, wer gewinnt?)

@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

[OffTopic]

Zitat von Mavarik:

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

Gruss vom MM Baujahr 56

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?