Bei diesem Thema herrscht eine Menge Verwirrung, deshalb hoffe ich, dass dieses Posting jedermann genau erklären wird, warum man diese Dinge nicht machen soll.
Ich möchte mit der Aussage beginnen, dass REPLIKATION eine verdammt coole Sache ist. Man kann Sachen damit tun, die anders einfach nicht möglich sind. Dieses Posting ist KEIN Flame gegen Replikation, es ist ein Flame gegen Leute, die sie anders einsetzen, als sie gedacht ist... und zeigt viele Gründe auf, warum diese Aktionen gefährlich für ihre Anwendungen und die Daten darin sind.
************************************
ZWECK DER REPLIKATION: Zwei oder mehr Kopien einer Jet-Datenbank zu haben, von denen man stets erwarten kann, dass sie immer eine Synchronisierung weit davon entfernt sind, identisch zu sein. Mehrere Leute können an mehreren Datenbanken Änderungen vornehmen, aber am Ende gibt es "Konvergenz" und jeder wird gleich weit sein. Unterstützt werden dabei verbundene und gelegentlich verbundene Anwender...aber auf keinen Fall nicht verbundene Anwender. Die Microsoft Jet-Replikation unterstützt kein Szenario, in dem es keine direkte, indirekte oder Internet-Verbindung gibt. Punkt.
************************************
HINTERGRUND BEIM VERSCHIEBEN/KOPIEREN: Microsoft Jet überprüft jedesmal, wenn es ein Replikat öffnet (zur Synchronisierung, oder Ihre Anwendung öffnet es, oder wie auch immer), ob das Replikat verschoben wurde. Das passiert durch Vergleich von Pfad und Maschine. Wenn es feststellt, dass es sich nicht am gleichen Ort befindet, nimmt es an, dass Sie ein Replikat kopiert haben und wird diesem Replikat grundsätzlich eine neue ReplicaID geben (es gibt schlimme Folgen für zwei Replikate mit der selben ReplicaID). Wenn Sie also eine Replikatgruppe mit vier Replikaten haben und Sie verschieben eines davon und öffnen es... dann denkt Jet, sie hätten FÜNF Replikate in der Replikatgruppe.
Das passiert in jedem der folgenden Szenarien:
1) Verschieben eines Replikates auf eine Diskette und Einsatz der Diskette, um an dem Replikat zu Hause oder irgendwo anders arbeiten zu können.
2) Direktes Datei verschieben/kopieren in DOS oder im Explorer
3) Verschieben des Replikates mithilfe einer Zip-Diskette, damit Sie auf zwei verschiedenen Maschinen/Pfaden damit arbeiten können..... sind die Namen der Maschinen und der Pfad nicht identisch, geht Jet von einer "Kopie" aus, sogar wenn Sie es auf der Zip-Diskette lassen und von dort synchronisieren.
4) Versenden des Replikates an jemand anderen per Email
5) Jede andere denkbare Kopier-Variante, Download von einer Internetseite oder von einem gemeinsamen Fileserver etc.
Es passiert nicht bei folgenden Szenarien:
1) Verwendung der eingebauten Methoden zum Verschieben eines Replikates, ob mit dem Menübefehl des Replikations-Managers oder mit der MoveReplica-Methode des TSI Synchronizers.
2) Verwendung des Aktenkoffers
Dieses Verhalten ruft einen Bug hervor, ein Ärgernis und drei wirklich schlimme Probleme, die "by design" sind und Beschädigung und/oder Datenverlust verursachen können.
************************************
BUG #1: Es gibt einen einzigen Bug bei der Art, wie Jet die Sache mit dem Wechsel der Replikat-ID behandelt...die Information darüber, welcher Synchronizer das betroffene Replikat managt, wird nicht aktualisiert. Wenn Sie also den Jet-Synchronizer für die Internet/Indirekte Synchronisierung verwenden und ein verwaltetes Replikat woanders hin kopieren, macht Jet ein neues Replikat daraus, denkt aber, es würde immer noch vom gleichen Synchronizer verwaltet. Wenn das nicht der Fall ist, können bei späteren Synchronisierungen etc. Probleme auftreten. Wenn es ein nicht verwaltetes Replikat war, werden Sie hingegen überhaupt keine Probleme bekommen. Mitarbeiter von Microsoft haben intern zugegeben, dass dieses Problem besteht, aber da das ganze Vorgehen undokumentiert ist, wurde es nicht als wichtig genug angesehen, um einen Fix in einem Service Release zu riskieren. Der Workaraound besteht darin, die Verwaltung aufzuheben etc. oder ein neues Replikat auf "legale" Weise zu erzeugen und damit ein nicht verwaltetes zu erhalten.
************************************
ÄRGERNIS #1: Wenn Sie diese Replikate verschieben/kopieren, wird die Liste der Replikate mit der Zeit immer länger und Sie werden immer mehr Replikate z.B. in der Replikatliste im Access-Dropdown-Menü Extras|Replikation|Jetzt synchronisieren und im Replikations-Manager sehen. Wenn Sie zwischen zwei Computern hin und her kopieren, dann haben alle diese falschen Replikate den gleichen Pfad...und sie können sich evtl. tausende von "c:\foo\bar.mdb"-Replikaten in der Liste einhandeln. Diese Einträge wieder loszuwerden ist nicht trivial. Im wesentlichen markiert Jet den Eintrag nur als gelöscht und gibt diese Info bei Synchronisierungen an andere Replikate weiter, wenn es zwar den Pfad, aber nicht die Datei findet... Wenn es also c:\foo\ finden kann, aber keine bar.mdb darin, wird der Eintrag gelöscht. Wenn Sie das 1000 Mal machen, werden diese tausend Einträge gelöscht. Es gibt andere nicht perfekte Varianten, um die falschen Replikate zu "entfernen", aber die sind noch weniger effektiv.
************************************
PROBLEM BY DESIGN #1: Microsoft Jet 3.5x hat eine Obergrenze von 64.000 Synchronizern, die einem Replikat "bekannt" sein können. Natürlich ist das bei den meisten Anwendungen kein Problem, aber denken Sie daran, dass Jet, wenn Sie ein Replikat nicht von einem Synchronizer verwalten lassen, einen "virtuellen" Synchronizer erzeugt, den Sie zum Synchronisieren mit einem echten Synchronizer verwenden könnten (sehr brauchbar z.B. bei der Internet-Synchronisierung!). Wenn Sie also immer wieder kopieren, kann es passieren, dass Sie 64.000 ungültige Replikate haben, und dann sind Sie geliefert. Sie haben Ihre Replikatgruppe beschädigt und können Sie nur mit sehr viel Arbeit wieder reparieren.
************************************
PROBLEM BY DESIGN #2: Datenkonflikte, die passieren, wenn zwei Leute die gleiche Spalte verändern, und die bei Jet 3.5 nur im verlierenden Replikat festgehalten werden. Sie haben also ein Replikat, das bei einem Konflikt verloren hat, und Sie haben das Replikat (zwischen dem Eingeben der Daten und dem Synchronisieren, bei dem der Konflikt festgestellt werden würde) verschoben, d.h. sie haben ein NEUES Replikat erzeugt, und deshalb verlieren Sie alle Daten, die ansonsten in den Konflikttabellen enthalten wären. Dieser DATENVERLUST ist ganz offensichtlich eine sehr ernste Sache.
************************************
PROBLEM BY DESIGN #3: Datenfehler, die passieren, wenn zwei Leute die Integrität der DB verletzen, sind schlimm (einfaches Beispiel ist das Einfügen des gleichen Primärschlüssels durch zwei Leute bei neuen Datensätzen und nachfolgender Synchronisierung). Jedesmal, wenn Sie synchronisieren, nimmt Jet an, Sie könnten die Probleme gelöst haben und würden die Synchronisierung erneut versuchen, um zu sehen, ob das Problem wirklich gelöst ist. Wenn Jet glaubt, dass das Problem noch immer vorhanden ist, stoppt es die Synchronisierung (damit passiert nichts weiter und keine weiteren Datensätze werden übertragen). Da die Information über einen Datenfehler sehr eng damit zusammenhängt, von welchem Replikat er stammt etc. ist es SEHR viel schwieriger, den Grund für einen Datenfehler zu finden, wenn das fragliche Replikat weg ist... ich kenne nur eine handvoll Leute, die solche Situationen lösen konnten, ohne die extreme Lösung des Entreplizierens/wieder neu Replizierens. Beachten Sie, dass Synchronisierungen NICHT ganz abgeschlossen werden, wenn es Datenfehler gibt... daher bekommen nicht alle Replikate alle Daten, und Sie haben einen inkonsistenten Zustand. Sie haben keinen Einfluss auf die Abfolge der Ereignisse, wenn das passiert.
************************************
CODA: Das ganze Szenario wurde (weil undokumentiert) niemals den umfassenden Stress-Tests unterworfen wie andere Abläufe. Wir machen vielleicht Späße über Microsofts Tests seiner Produkte, aber tatsächlich sind Stress-Tests eine ganz entscheidende Sache. Da hier nie getestet wurde, könnten zusätzlich zu den o.a. Problemen (die ich über mehrere Jahre gefunden, identifiziert und gefixt habe) noch weitere bestehen, die bisher noch nicht gefunden wurden. Ironischerweise, führen jene Leute, die MS sonst am stärksten für Bugs in seinen Produkten kritisieren, diese Beschwerde nicht.
Für's Protokoll: Bevor die Jet-Replikation erstmals ausgeliefert wurde (für Jet 3.0), war KEINES der o.a. Probleme bekannt oder wurde verstanden. DENNOCH habe ich immer den Rat erteilt, dass man niemals ein Replikat, das Daten enthält, verschieben oder kopieren soll. Der Grund dafür ist, dass *ich* dem Rat gefolgt bin, keine nicht dokumentierten Dinge zu tun. Deshalb hatte nie eine von mir erstellte Anwendung IRGENDEINES dieser Probleme. Ich habe jedoch persönlich in den letzten Jahren bei der Wiederherstellung von mehr als 70 verschiedenen Anwendungen geholfen, die schwere Probleme aus den hier angeführten Ursachen hatten. Die geschätzten Gesamtkosten sind HOCH, weil die Leute stur weiterhin diese Dinge tun und die Warnungen missachten.
************************************
Also warum nicht nicht "wie Mike sein" :-) und einfach keine Sachen probieren, die undokumentiert und ungetestet sind, besonders da nun bewiesen ist, dass sie große Probleme verursachen?
