Available with Standard or Advanced license.
Geodatabase replication is built on top of traditional versioning. During replica creation, versions from the source and target enterprise geodatabases are set as replica versions. Changes in these replica versions are exchanged during synchronization. Since the replica versions are linked, you can think of them as a way to extend the version tree to span multiple geodatabases.
The default version or any named version can be used as the replica version for the parent or child replica. Several replicas can also share the same replica version.
One-way and two-way replicas
The diagram below shows the replica versions for one-way replicas and two-way replicas. For the two-way replication, the parent replica uses the named version RV1 as the replica version. The parent replica in the one-way replication examples uses the named version RV2 as the replica version for both examples.
For both child replicas hosted in enterprise geodatabases, the default version is the replica version. Other than the fact that they are used for replication, the replica versions are no different from other versions. Since file geodatabases do not support versioning, no replica version is created in the child geodatabase in a one-way replica.
Note:
It is also possible to use a named version as the replica version in either enterprise geodatabase in the diagram below.
Checkout replicas
Checkout/Check-in replication is capable of replicating both versioned and nonversioned data, and the child replica can be hosted on a file geodatabase or an enterprise geodatabase.
When a child replica is hosted on an enterprise geodatabase, a new named version is created to facilitate editing and serve as the replica version on the child replica. The name of the child replica version is set to be the same as the name of the replica. To edit the child replica data, connect to the enterprise geodatabase and use either the Geodatabase Connection Properties dialog box or the Change Version dialog box to change the version to the child replica version. Once connected to the child replica version, you can start an editing session. The edits must be performed in the child replica version in order to synchronize the edits back to the parent replica.
When using checkout/check-in replication, a new version is created with the name of the replica. The combination of user name and replica name must be unique. For example, user1 and user2 could each create a replica named MyReplica because the full replica names would be user1.MyReplica and user2.MyReplica. However, user1 could not create more than one replica named MyReplica because that replica name would not be unique.
Checkout/Check-in replication also allows file geodatabases to host child replicas. Since these geodatabase types don't support versioning, no replica version is created for the child. This is also the case when checking out nonversioned data. For these scenarios, additional logic is used to determine the changes to send during synchronization.
The diagram below shows two examples of checkout/check-in replicas and their replica versions. One parent replica uses version RV1 as the replica version, while the other uses version RV2 as the replica version. One child replica is hosted by a file, and the other is hosted by an enterprise geodatabase. For the enterprise geodatabase hosting the child replica, RV2 was automatically created and set as the replica version during creation. The name RV2 for this replica version was taken from the name of the replica. This replica version is where edits are to be performed on the child for synchronizing back to the parent.
Dive-in:
For checkout/check-in replicas, a synchronization version is added to the parent replica's geodatabase during creation. The synchronization version is a child of the replica version but is not shown above, since it is used only during synchronization. See Synchronization and versioning for more information.
Use archiving to track replica changes
For one-way replication only, you can use archiving instead of versioning to keep track of replica changes. For this option, the parent geodatabase must be an enterprise geodatabase referencing the default version. The advantage to managing replication in this way is that it keeps the reconcile, post, and compress processes separate from the synchronization process.
When versioning is used to track changes, system versions are created. Because of these system versions, you need to synchronize regularly to achieve an effective compress. When archiving is used to track replica changes, no system versions are created. Therefore, the reconcile, post, and compress processes are not affected, making version management and replication management independent. This also allows the synchronization schedule to be more flexible. To use archiving to track replica changes, the source data must be registered as versioned in the enterprise geodatabase and the source replica version must be the default version.
In the diagram below, one-way parent-to-child replication using archiving between enterprise geodatabases is shown, in which the default version is used as the replica version for both the parent and child replicas in the enterprise geodatabase. Since file geodatabases do not support versioning, no replica version is created on the child file geodatabase.
One-way child-to-parent replication can also be used when both geodatabases are enterprise geodatabases. The child replica version must be the default in this case.
Related topics
See the following related help topics for more information: