Hmm ... das "Update-Liste pro Client"-Konzept ist auch eine Lösung.
Allerdings muß hier geklärt sein, welche
DB die Master-
DB stellt.
Wenn ich den TO richtig verstanden habe, wird auf beiden DBs aktiv gearbeitet.
Die Synchronisation muß also in beiden Richtungen stattfinden. Und da kommt man an einem Zeitstempel nicht vorbei. Allzumal die Synchronisation nicht zeitgleich passiert sondern mit Sicherheit in bestimmten zeitlichen Intervallen.
Wie soll man verhindern, das z.B. Online ein Termin gelöscht und gleichzeitig (im gleichen Zeitintervall) der selbe Termin lokal nur verschoben wird. Oder auch umgekert. Das sind zwei unterschiedliche Vorgänge auf ein und die selbe Information (sprich Datensatz)!
Selbst ein Mischen und Sortieren der Updatelisten beider DBs kann zu Datenverlust führen.
Löschen von Datensätzen, die mit anderen
DB's Synchronisiert werden sollen, halte ich daher immer für einen schlechte Idee. Eine Löschmarkierung ist hier der bessere Weg.
Ich glaube grundsätzlich kann man sagen, dass das Synchronisieren von zwei (oder mehreren) DBs immer ein Problem darstellt und sollte immer von Anwendungsfall zu Anwendungsfall neu überdacht werden.
Meines Erachtens ist es das wichtigste, das Termine (Datensätze) auf allen DBs einen eindeutigen ID besitzen, damit man sie jederzeit identifizieren kann.
Zitat von
BUG:
Nett wäre hier, wenn nicht ein anderer Client gleichzeitig auch versucht zu synchronisieren.
Das definitiv.