Mit der Standard- oder Advanced-Lizenz verfügbar.
Bei der bidirektionalen und der unidirektionalen Replikation werden die Filter und die Regeln für Beziehungsklassen, die bei der Replikaterstellung angewendet wurden, auch bei der Synchronisierung angewendet (mit Ausnahme der Filter, die auf einem Auswahlsatz basieren). Zum Ermitteln der zu übertragenden Änderungen werden alle Änderungen in jedem Replikat-Dataset ausgewertet, die seit der letzten Synchronisierung angewendet wurden. Wenn eine Änderung die Kriterien der Replikatfilter erfüllt, wird sie synchronisiert.
In der folgenden Grafik wird veranschaulicht, wie der Replikatbereichsfilter bei der Synchronisierung angewendet wird, wenn Features in einer Editiersitzung verschoben werden. Die folgenden Änderungen werden bei der Synchronisierung an das relative Replikat übertragen:
- Ein Feature wird im Replikatbereich an eine neue Position verschoben.
- Ein Feature wird aus dem Replikatbereich verschoben. Die neue Position des Features wird bei der Synchronisierung im relativen Replikat aktualisiert, selbst wenn es außerhalb des Replikatbereichs liegt.
- Ein Feature wird von außerhalb des Replikatbereichs in den Replikatbereich verschoben.
Wenn ein Feature verschoben wird, das sich nicht im Replikatbereich befindet (Szenario 4), wird es bei der Synchronisierung im relativen Replikat nicht aktualisiert.
Filter, die auf Auswahlsätzen basieren, werden während der Replikaterstellung angewendet, aber beim Synchronisieren ignoriert. Beim Synchronisieren wird der Filter für einen Auswahlsatz so behandelt, als ob er "all_rows" lautet. Wenn beispielsweise bei der Replikaterstellung die zu replizierenden Zeilen einer Tabelle nur mit einem Auswahlsatz definiert werden, werden während der Synchronisierung alle Änderungen der Tabelle übernommen. Wenn bei der Replikaterstellung die zu replizierenden Zeilen einer Tabelle mit einem Auswahlsatz und anderen Filtern definiert werden, werden während der Synchronisierung nur die anderen Filter angewendet. Wenn beispielsweise bei der Replikaterstellung ein Auswahlsatz und eine Definitionsabfrage angewendet werden, wird während der Synchronisierung nur die Definitionsabfrage angewendet.
Wenn die zu replizierenden Daten Beziehungsklassen aufweisen, wirkt sich dies auf den Synchronisierungsvorgang aus. Im Folgenden wird beschrieben, wie Beziehungsklassen bei der Synchronisierung verarbeitet werden.
Wenn eine Änderung den Bedingungen der Filter nicht gerecht wird, wird sie möglicherweise dennoch synchronisiert, wenn sie die folgenden Kriterien erfüllt:
- Sie gehört zu einem Dataset mit einem Nur-Schema-Filter und ist in mindestens eine Beziehungsklasse eingebunden.
Außerdem muss eine der folgenden Bedingungen erfüllt sein:
- Sie ist auf eine Zeile in einem anderen Dataset bezogen, die die Filterkriterien erfüllt. Die Zeile, auf die sie bezogen ist, muss seit der letzten Synchronisierung nicht bearbeitet worden sein.
- Sie befindet sich in einem Dataset, das auf ein Dataset mit einem Nur-Schema-Filter bezogen ist.
Dies bedeutet, dass Zeilen in Feature-Classes oder Tabellen mit anderen Filtern als "Nur Schema" nur synchronisiert werden können, wenn sie die Filterkriterien erfüllen.
Diese Regeln ermöglichen auch das Verketten in Beziehung stehender Daten. Dies kann der Fall sein, wenn eine Zeile in einer entfernten Zielklasse durch Beziehungsklassen über mehrere Beziehungen hinweg auf den Ursprung im Replikat zurückverfolgt werden kann.
Beispiel
In diesem Beispiel sind drei Gebäude für die Replikation ausgewählt. Da bei der Replikaterstellung in Beziehung stehende Datensätze berücksichtigt werden, wird auch die in Beziehung stehende Zielklasse repliziert. Felder in der Zielklasse, die in Beziehung zu den Ursprungs-Features stehen, werden im Child-Replikat geändert. Beim Synchronisieren der Replikate werden diese Änderungen in der in Beziehung stehenden Zielklasse im Parent-Replikat aktualisiert.
Beibehalten von Beziehungen
Bei der Synchronisierung werden Beziehungen beibehalten. Wenn z. B. im relativen Replikat eine neue Beziehung hinzugefügt wird, wird diese beibehalten, wenn die betreffenden Zeilen synchronisiert werden. Wenn der ursprüngliche Schlüssel ein ObjectID-Feld ist, muss für die Beibehaltung der Beziehung möglicherweise der Fremdschlüsselwert für das Replikat geändert werden, das die Änderungen empfängt.
In den folgenden Beispielen wird das Verhalten in Beziehung stehender Datensätze bei der Synchronisierung veranschaulicht:
Beispiel 1
In diesem ersten Beispiel wurden einige Features in einer Ursprungsklasse (Gebäude) für die Replikation ausgewählt. Die Gebäude stehen über eine Beziehung ohne Attribute in Beziehung mit Attributdatensätzen in einer Tabelle, die aus der Replikation ausgeschlossen wurden. Während der Bearbeitung des Child-Replikats wurde ein Gebäude gelöscht. Bei der Synchronisierung wird der entsprechende Eintrag im Fremdschlüsselfeld in der in Beziehung stehenden Zielklasse (die Tabelle) auf NULL festgelegt, um die Beziehung mit dem gelöschten Feature aufzuheben.
Dieses Synchronisierungsverhalten kann auch zur Löschung von Zeilen führen, die Beziehungen in einer Beziehungsklassen-Tabelle mit Attributen darstellen (wie im nächsten Beispiel veranschaulicht).
Beispiel 2
In diesem Beispiel weist die Beziehung zwischen der Ursprungs-Feature-Class und der Zielklassentabelle Attribute auf. Das heißt, die Beziehung selbst verfügt über eine zugeordnete Tabelle. Sowohl die Beziehungsklasse als auch die Zielklasse wurden von der Replikaterstellung ausgeschlossen. Änderungen, die an der Ursprungs-Feature-Class im Child-Replikat vorgenommen wurden, haben dazu geführt, dass ein Feature gelöscht wurde. Bei der Synchronisierung wird die Zeile in der mit Attributen versehenen Beziehungsklassen-Tabelle gelöscht, die die Beziehung des betreffenden Features zu einem Objekt in der Zielklasse darstellt.
Bei der Synchronisierung werden nur Beziehungen gelöscht; in Beziehung stehende Objekte selbst werden in keinem Fall gelöscht.
