Replica creation and versioning

Available with Standard or Advanced license.

Geodatabase replication is built on top of versioning. During replica creation, versions from the source and target 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. See Creating a checkout replica to learn how to set the replica version on either the parent or child.

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.

Note:

It would also have been possible to create all these replicas from the same named version, all from the default version, or any combination of named versions and the default version.

For both child replicas hosted in an 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, such as V1 and V2 shown below. Since file and personal geodatabase types do not support versioning, no replica version is created in the child in the second one-way replication, shown on the right.

Note:

It is also possible to use a named version as the replica version in either enterprise geodatabase in the diagram below.

Checkout/check-in replication is capable of replicating both versioned and nonversioned data and the child replica can be hosted in a personal, file, 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 the Change Versions dialog box to change the version to the child replica version. Once connected to the child replica version, you can proceed to start an editing session. The edits must be performed in the child replica version to synchronize the edits back to the parent replica.

Checkout/check-in replication also allows personal or 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 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 geodatabase (this could also be a personal geodatabase), 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 version in the parent that was used to create it.

Dive-in:

For checkout 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.

Using 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 manner 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 and personal geodatabase types do not support versioning, no replica version is created on the child file or personal geodatabase.

One-way child-to-parent replication can also be used when both geodatabases are enterprise geodatabases. The child replica version must be default in this case.