Synchronization and versioning(ArcInfo and ArcEditor only)
Release 9.3 Last modified April 2, 2009	Print all topics in : "Managing Distributed Data"

Geodatabase replication uses versioning during the synchronization process. 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 re-sent. For checkout replicas in file or personal geodatabases, an internal table containing all edits is analyzed.
  
• Receiving Changes—When a replica receives changes, the following occurs:
  


1. 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 till synchronization time, while for checkout replicas, the version is created at creation time.
   





2. 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. See Synchronizing connected replicas and Synchronizing disconnected replicas to see how to apply these options in connected and disconnected environments. 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, to reconcile and post are optional and 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.
  





3. 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 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.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.