Synchronization and versioning

This topic applies to ArcEditor and ArcInfo only.

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.

rep_syncver1

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

rep_syncver2.gif

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.

rep_syncver3
NoteNote:
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.

1/5/2011