For two-way and one-way replication, the same filters and relationship class rules used in replica creation are applied during synchronization. When determining the changes to send, all edits in each replica dataset that have been applied since the last synchronization are evaluated. If an edit satisfies the replica's filters, it is synchronized.
Note:
For checkout/check-in replicas, all edits made on the child replica are synchronized. Therefore, the following rules, except for those in the Maintaining relationships section, do not apply to checkout/check-in replicas.
The image below depicts how the replica area filter is applied during synchronization when features are moved in an edit session. The following edits are sent to the relative replica during synchronization:
- A feature is moved to a new location inside the replica area.
- A feature is moved out from inside the replica area. The feature's new location is updated on the relative replica during synchronization even though it lies outside the replica area.
Note:
For the edit to be sent, the feature must have existed inside the replica filter at the time of the previous synchronization. For example, if you insert a feature, move it out, and then synchronize with the relative replica, these changes are not sent.
- A feature is moved from outside the replica area into the replica area.
- When a feature is moved that is not within the replica area, it is not updated on the relative replica during synchronization.
If an edit does not satisfy the filters, it may still be synchronized if it meets the following criteria:
- It belongs to a dataset with a schema-only filter and is involved in at least one relationship class.
- It also meets one of the following:
- It is related to a row in another dataset that satisfies the filters. The row that it is related to does not have to have been edited since the last synchronization.
- It is in a dataset that is related to a dataset with a schema-only filter.
This means that rows in feature classes or tables that have filters other than schema only can only be synchronized if they meet the filter criteria.
These rules also allow chaining of related data. This can occur when, through relationship classes, a row in a distant destination class can be traced back through multiple relationships to the origin in the replica.
Maintaining relationships
Synchronization maintains relationships. For example, if a new relationship is added in the relative replica, it is maintained when the rows involved are synchronized. Maintaining the relationship may require changing the foreign key value on the replica receiving changes if the origin key is the objectID field.
The following examples describe the behavior of related records during synchronization:
Example
In this example, three buildings are selected for replication via a definition query. Because related records are included in the replica creation process, the related destination class is also replicated. Fields in the destination class related to the origin features are edited on the child replica. When the replicas are synchronized, these edits are updated on the related destination class in the parent replica.
Example one
In this first example, some features in an origin class, buildings, were selected for replication. The buildings are related through a simple relationship class to attribute records in a table that were excluded from the replication. During editing on the child replica, a building was deleted. On synchronization, to void the relationship with the feature that was deleted, the corresponding entry in the foreign key field in the related destination class, the table, is set to NULL.
This synchronization behavior may also result in the deletion of rows representing relationships in an attributed relationship class table (as seen in the next example).
Example two
In this example, the relationship between the origin feature class and the destination class table is attributed, which means the relationship itself has an associated table. Both the relationship and the destination class were excluded in the replica creation process. Edits made to the origin feature class on the child replica resulted in one feature being deleted. On synchronization, the row in the attributed relationship class table representing this feature’s relationship to an object in the destination class is removed.
Only relationships are deleted on synchronization; related objects themselves are never deleted.
