Synchronizing with filters and related data

This topic applies to ArcEditor and ArcInfo only.

For two-way and one-way replication, the same filters and relationship class rules used in replica creation are applied during synchronization, with the exception of filters based on a selection set. 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 will be 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 graphic below depicts how the replica area filter is applied during synchronization when features are moved in an edit session. The following edits will be sent to the relative replica during synchronization:

1. A feature is moved to a new location inside the replica area.
2. A feature is moved out from inside the replica area. The feature's new location will be 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, then synchronize with the relative replica, these changes will not be sent.
3. 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 (scenario 4), it does not get updated on the relative replica during synchronization.

Filters based on selection sets are applied during replica creation but are ignored during synchronization. The synchronization process treats a selection set filter as if it is all rows. For example, if only a selection set is used to define the rows to replicate from a table during replica creation, all changes made to that table are applied during synchronization. If a selection set and other filters were used to define the rows to replicate from a table during replica creation, only the other filters are applied during synchronization. For example, if a selection set and a definition query are applied during replica creation, only the definition query is applied during synchronization.

If the data that you are replicating includes relationship classes, it will have an effect on the synchronization process. The following describes how relationship classes are applied 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 must also meet 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.

Example

In this example, three buildings are selected for replication. 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.

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 one

In this first example, some features in an origin class, buildings, were selected for replication. The buildings are related through a nonattributed relationship 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.