Mit der Standard- oder Advanced-Lizenz verfügbar.
Bei der Geodatabase-Replikation wird während des Synchronisierungsvorgangs für Replikate, die in Enterprise-Geodatabases gehostet werden, eine Versionierung verwendet. Eine Ausnahme stellt die Verwendung der Archivierung zum Nachverfolgen von Änderungen in einer unidirektionalen Replikation dar.
Die Versionierung dient dazu, Änderungen zu ermitteln und diese zu senden sowie Änderungen zu empfangen. Im Folgenden wird beschrieben, wie die Versionierung in diesen Prozessen verwendet wird:
Senden von Änderungen
Wenn ein Replikat Änderungen sendet, werden Replikatversion (bei der Replikaterstellung festgelegt) und Systemversionen analysiert. Bei dieser Analyse werden möglicherweise Änderungen herausgefiltert, die bereits bei früheren Synchronisierungen gesendet wurden, oder es wird festgestellt, dass einige Änderungen erneut gesendet werden müssen. Bei Check-Out-Replikaten in Personal- oder File-Geodatabases wird eine interne Tabelle mit allen Änderungen analysiert. Bei einer unidirektionalen Replikation mittels Archivierung wird die Archivklasse analysiert, um zu ermitteln, welche Änderungen gesendet werden sollen.
Empfangen von Änderungen
Wenn ein Replikat Änderungen empfängt, geschieht Folgendes:
Zunächst werden die Änderungen auf die Synchronisierungsversion angewendet. Die Synchronisierungsversion ist der Replikatversion untergeordnet. Sie wurde konzipiert, um diese Änderungen vorübergehend zu speichern, bis sie abgeglichen und in die Replikatversion zurückgeschrieben wurden. Bei bi- und unidirektionalen Replikaten kann die Version erst bei der Synchronisierung erstellt werden. Bei Check-Out-Replikaten wird die Version dagegen zur Erstellungszeit erstellt. In den Abbildungen weiter unten kann die Replikatversion DEFAULT sein oder es kann sich um eine benannte Version handeln.
Anschließend wird die Synchronisierungsversion mit der Replikatversion abgeglichen. Das Verhalten in diesem Schritt hängt vom Replikattyp ab:
- Bidirektionale Replikate: Bei bidirektionalen Replikaten können beim Abgleichen Konflikte auftreten. Wenn es zu Konflikten kommt, wird mithilfe einer Abgleichmethode ermittelt, wie mit diesen Konflikten zu verfahren ist. Sie können zwischen automatischen und manuellen Abgleichmethoden bei der Synchronisierung wählen. Wenn keine Konflikte vorhanden sind bzw. nachdem Konflikte durch eine automatische Abgleichmethode gelöst wurden, wird die Replikatversion mit der Synchronisierungsversion zurückgeschrieben.
- Check-Out-Replikate: Bei Check-Out-Replikaten sind Abgleich- und Zurückschreibprozesse optional und werden nicht standardmäßig ausgeführt. Wenn Sie keinen Abgleich- und Zurückschreibprozess ausführen möchten, bleiben die Änderungen in der Synchronisierungsversion. In diesem Fall können Sie den Abgleich- und Zurückschreibprozess zu einem späteren Zeitpunkt ausführen. Wenn Sie einen Abgleich- und Synchronisierungsprozess ausführen möchten, entspricht das Verhalten dem bei einem bidirektionalen Replikat.
- Unidirektionale Replikate: Bei unidirektionalen Replikaten werden Änderungen in der Replikatversion immer überschrieben und es entstehen nie ungelöste Konflikte. Wenn ein einfacher Modelltyp verwendet wird, müssen die Daten des Child-Replikats nicht versioniert werden. In diesem Fall werden die Änderungen direkt auf die Basistabellen angewendet und die Versionierung wird beim Empfangen der Änderungen nicht verwendet. Änderungen werden auch dann direkt überschrieben, wenn das Child-Replikat in einer Personal- oder File-Geodatabase gehostet wird.
Once the changes have been posted to the replica version, the synchronization version will be deleted. Wenn Sie eine manuelle Abgleichmethode auswählen und es zu Konflikten kommt, liegt es an Ihnen, den Abgleich- und Zurückschreibprozess selbst zu einem späteren Zeitpunkt durchzuführen. Bei bidirektionalen Replikaten liegt für das Replikat ein Konflikt vor, solange die Synchronisierungsversion vorhanden ist. Solange ein Konflikt vorliegt, können vom Replikat zwar Änderungen empfangen, aber nicht gesendet werden.
