Available with Standard or Advanced license.
Geodatabase replication uses versioning during the synchronization process for replicas hosted in enterprise geodatabases. Versioning is used to determine the changes that are to be sent and received. The exception is when you are using archiving to track changes in a one-way replication.
The following describes how versioning is used in each of these synchronization processes:
Send changes
When a replica sends changes, the replica version (defined during replica creation) and system versions are analyzed. This analysis may filter out edits that have been previously sent during earlier synchronization or determine that some changes need to be sent again. For checkout/check-in replicas in file 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.
Receive 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 designed to temporarily hold synchronized 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 the time of synchronization, while for checkout/check-in replicas, the version is created at the time of replica creation. In the diagrams below, the replica version could be either the default version or a named version.
Next, the synchronization version is reconciled against the replica version. The behavior at this step is dependent on the replica type:
- Two-way replicas—For two-way replicas, there can be conflicts during the reconcile. If conflicts are detected, a conflict resolution policy is used to determine how these should be handled. If there are no conflicts, or conflicts are resolved by an automatic conflict resolution policy, the replica version is posted with the synchronization version.
- Checkout/check-in replicas—For checkout/check-in replicas, the reconcile and post process is optional and is not run by default. If you choose not to reconcile and post, the changes will remain in the synchronization version. You can then reconcile and post manually at a later time. If you decide to reconcile and post, the behavior is the same as seen with a two-way replica.
- One-way replicas—For one-way replicas, changes in the replica version are always overwritten, and unresolved conflicts are not created. When using a simple model type, the data in the child replica does not have to be versioned. If the child replica is not versioned, changes are applied directly to the base tables. Changes are also directly overwritten in cases in which the child replica is hosted in a file geodatabase.
Once the changes have been posted to the replica version, the synchronization version is deleted. 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 signed 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 signed in as the replica version owner.