Problem ist auch noch, dass mehrere Windows Rechner (Firebird) die gleiche
MySQL Datenbank synchronisieren. Eine Änderung an Platz1 wird dann auf Platz2 verteilt usw.
Kurze Frage, damit ich das korrekt verstanden habe: Du synchronisierst EINE Firebird-
DB (Win-Client) mit EINER
MySQL-
DB (online), oder MEHRERE Firebird-
DB's (eine pro Client) mit EINER
MySQL-
DB?
Sollte letzteren der Fall sein, muß ich fragen: Wieso? Ist doch Quatsch!
Ich denke aber, der erste Fall wird zutreffen sein, oder?
Dann stell ich Dir die Frage: Wieso synchronisieren die einzelnen Win-Clients die
MySQL-
DB?
Wenn jeder Client die
MySQL-
DB synchronisiert, muß das (vom Gefühl her schon) in die Hose gehen!
Die Idee von SX2008 würde ich _so_ eher nicht verfolgen.
Einen Hashwert über die Adresse zur Synchronisation von Terminen würde ich nicht verwenden. Das Eine hat (im Prinzip) nichts mit dem Anderen zu tun! Adressen können sich ändern! Und das tun sie heufiger, als man als Entwickler denkt.
Selbst wenn man sagt, Okay, der Hashwert wird einmalig erzeugt, beim Anlegen beispielsweise. Die Praxis zeigt, das der EndNutzer gern im Eifer des Gefechtes (Telefonat, Kundengespräch usw.) nur einen Namen (z.B. "Frau Müller") als Adresse anlegt, evtl. einen Termin dazu, und erst später die komplette Adresse nachträgt. Den EndNutzer zur Eingabe der komplette Adresse zu "zwingen" ist eher kontra-produktiv und das Thema wird schnell auf wieder auf deinem Desktop liegen.
Dein
DB-Konzept zur Synchronisation hört sich recht gut an.
Was ich allerdings ändern würde, wäre das nicht die Clients die Synchronisation der
MySQL-
Db vornehmen, sondern das das Ganze an einer zentralen Stelle passiert. Das könnte ein System-Dienst auf dem lokalen
DB-Server übernehmen.
Dann brauchen deine Termine einen eindeutigen ID. Deshalb verpasst du den Terminen neben dem Zeitstempel, der die letzte Änderung des Termins beschreibt (nennen wir ihn Änderungsstempel), einen weiteren Zeitstempel, der die Erstellung des Termins beschreibt, mit einer zusätzlichen Kennung in welcher
DB der Termin erstellt wurde. Den nennen wir "Erstellstempel" oder einfach ID, dann das wäre dann einer.
Wichtig: Für beide Zeitstempel nutzt du die Zeit des jeweiligen
DB-Servers, nicht die des Clients! D.h. im
SQL-Statement Now()!!
Die zusätzlich
DB-Kennung deswegen, weil die Zeiten der beiden
DB's bzw. deren Server nicht zu 100% synchron sein werden.
Den Surrogatschlüssel ala Hashwert, den SX2008 beschreibt, den hättest du dann mit dem Erstellstempel, sprich ID, unabhängig von der Adresse. Und der ist mit Sicherheit eindeutig und enthält sogar mehr Information!
Kurz um: Lass die Synchronisation von einem zentralen Dienst auf dem lokalen
DB-Server übernehmen und Dir dürfte kein Termin mehr durch die Lappen gehen. Dadurch, das nun jeder Termin einen eindeutigen ID (Erstellstempel) besitzt, entscheidet der Änderungsstempel, welcher Termin "Master" ist.