Mit der Standard- oder Advanced-Lizenz verfügbar.
Bei der Geodatabase-Replikation wird die Versionierung während des Synchronisierungsvorgangs für Replikate verwendet, die in ArcSDE-Geodatabases gehostet werden. Eine Ausnahme ist die Verwendung der Archivierung zum Verfolgen von Änderungen bei einer unidirektionalen Replikation.
Die Versionierung dient der Ermittlung der zu sendenden Änderungen und wird auch beim Empfang von Änderungen verwendet. Im Folgenden wird die Verwendung der Versionierung bei diesen Vorgängen beschrieben:
Senden von Änderungen
Wenn ein Replikat Änderungen sendet, ermittelt ArcSDE die zu sendenden Änderungen anhand einer Analyse der Replikatversion (definiert während der Replikaterstellung) und einiger Systemversionen. Bei dieser Analyse werden ggf. Änderungen herausgefiltert, die bereits bei früheren Synchronisierungen gesendet wurden. Außerdem wird möglicherweise ermittelt, dass manche Änderungen erneut gesendet werden müssen. Bei Check-Out-Replikaten in File- oder Personal-Geodatabases wird eine interne Tabelle mit allen Änderungen analysiert. Bei der unidirektionalen Replikation mit der Archivierung wird die Archivklasse analysiert, um die zu sendenden Änderungen zu bestimmen.
Empfangen von Änderungen
Wenn ein Replikat Änderungen empfängt, treten folgende Ereignisse ein:
Zuerst werden die Änderungen auf die Synchronisierungsversion angewendet. Die Synchronisierungsversion ist eine Child-Version der Replikatversion. Sie dient der temporären Speicherung der Änderungen, bis diese abgeglichen und in die Replikatversion zurückgeschrieben wurden. Bei bidirektionalen und unidirektionalen Replikaten wird die Version möglicherweise erst bei der Synchronisierung erstellt, bei Check-Out-Replikaten jedoch stets bereits bei der Erstellung. In den Abbildungen unten kann die Replikatversion entweder DEFAULT oder eine benannte Version sein.
Als Nächstes wird die Synchronisierungsversion mit der Replikatversion abgeglichen. Das Verhalten bei diesem Schritt hängt vom Replikattyp ab:
- Bidirektionale Replikate – Während des Abgleichs können Konflikte auftreten. In diesem Fall wird anhand einer Abgleichmethode bestimmt, wie die Konflikte behandelt werden. Sie können bei der Synchronisierung zwischen automatischen und manuellen Abgleichmethoden wählen. Wenn keine Konflikte bestehen oder die Konflikte durch eine automatische Abgleichmethode gelöst werden, wird die Replikatversion in die Synchronisierungsversion zurückgeschrieben.
- Check-Out-Replikate – Das Abgleichen und Zurückschreiben ist für Check-Out-Replikate optional und wird in der Standardeinstellung nicht ausgeführt. Wenn Sie die Daten nicht abgleichen und zurückschreiben, verbleiben die Änderungen in der Synchronisierungsversion. Sie können das Abgleichen und Zurückschreiben dann später manuell vornehmen. Wenn Sie die Daten jedoch abgleichen und zurückschreiben, entspricht das Verhalten dem bei bidirektionalen Replikaten.
- Unidirektionale Replikate – Änderungen an der Replikatversion werden stets überschrieben, und ungelöste Konflikte sind nicht möglich. Wenn Sie einen einfachen Modelltyp verwenden, sind die Daten des Child-Replikats möglicherweise nicht versioniert. In diesem Fall werden die Änderungen direkt auf die Basistabellen angewendet. Die Versionierung wird beim Empfang von Änderungen nicht verwendet. Änderungen werden zudem direkt überschrieben, wenn das Child-Replikat in einer Personal- oder File-Geodatabase gehostet wird.
Sobald die Änderungen in die Replikatversion zurückgeschrieben wurden, wird die Synchronisierungsversion gelöscht. Wenn Sie eine manuelle Abgleichmethode auswählen und Konflikte auftreten, können Sie entscheiden, die Daten zu einem späteren Zeitpunkt abzugleichen und zurückzuschreiben. Bei bidirektionalen Replikaten wird das Replikat so lange als in Konflikt stehend behandelt, wie die Synchronisierungsversion vorhanden ist. Solange der Konflikt besteht, können vom Replikat Änderungen empfangen, aber nicht gesendet werden.
