Synchronization and versioning

Available with Standard or Advanced license.

Geodatabase replication uses versioning during the synchronization process for replicas hosted in ArcSDE geodatabases. The exception is when you are using archiving to track changes in a one-way replication.

Versioning is used to determine the changes to send and also when receiving changes. The following describes how versioning is used in each of these processes:

Sending Changes

When a replica sends changes, ArcSDE determines which edits to send by analyzing the replica version (defined during replica creation) and some system versions. This analysis may filter out edits that have already been sent during earlier synchronizations or determine that some changes need to be resent. For checkout replicas in file or personal geodatabases, an internal table containing all edits is analyzed. For one-way replication using archiving, the archive class is analyzed to determine what changes to send.

Receiving Changes

When a replica receives changes, the following occurs:

First, the changes are applied to the synchronization version. The synchronization version is a child of the replica version. It is designed to temporarily hold these changes until they are reconciled and posted to the replica version. For two-way and one-way replicas, the version may not be created until synchronization time, while for checkout replicas, the version is created at creation time. In the diagrams below, the replica version could be either DEFAULT or a named version.

Next, the synchronization version is reconciled against the replica version. The behavior at this step depends on the replica type:

• Two-way replicas—For two-way replicas, there can be conflicts during the reconcile. If there are conflicts, a reconcile policy is used to determine how to handle the conflicts. You can choose between automatic and manual reconcile policies during synchronization. If there are no conflicts, or conflicts are resolved by an automatic reconcile policy, the replica version is posted with the synchronization version.
• Checkout replicas—For checkout replicas, reconciling and posting are optional and are not executed by default. If you choose to not reconcile and post, the changes remain in the synchronization version. You can then reconcile and post manually at a later time. If you do decide to reconcile and post, the behavior is the same as with two-way replicas.
• One-way replicas—With one-way replicas, changes in the replica version are always overwritten, and there are never unresolved conflicts. When using a simple model type, the child replica's data may not be versioned. If this is the case, changes are applied directly to the base tables, and versioning is not used when receiving changes. Changes are also directly overwritten for cases where the child replica is hosted in a personal or file geodatabase.

Once the changes have been posted to the replica version, the synchronization version will be deleted. If you choose a manual reconcile policy, and there are conflicts, it is up to you to perform the reconcile and post on your own at a later time. For two-way replicas, as long as the synchronization version exists, the replica is considered in conflict. While in conflict, changes can be received by but not sent from the replica.

Note:

It is recommended that you perform the reconcile and post while logged in as the owner of the replica. By default, the synchronization version is private and can only be accessed by the replica owner. If you make this version public, you can reconcile and save changes as a user other than the replica owner. However, you must post the changes while logged in as the replica owner.