Replica creation and versioning

This topic applies to ArcGIS for Desktop Standard and ArcGIS for Desktop Advanced only.

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 replica to see 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/or the default version.

For both child replicas hosted in ArcSDE 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.

Note:

It would have also been possible to use a named version as the replica version in either ArcSDE geodatabase in the diagram below.

Since file and personal geodatabase types don't support versioning, no replica version is created for the child in the second one-way replication, shown on the right.

Checkout replication is capable of replicating both versioned and nonversioned data. For checkout replicas involving versioned data, a new named version is created to serve as the replica version on the child.

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 ArcSDE geodatabase. For the ArcSDE 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.

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 choose to use archiving instead of versioning to keep track of replica changes. For this option, the source replica version must be the DEFAULT version.

The advantage to managing replication in this manner is that it keeps the reconcile and post and compress processes separate from the synchronization process. When versioning is used to track changes, system versions are created. Due to these system versions, you need to synchronize regularily in order to achieve an effective compress.

When archiving is used to track replica changes, no system versions are created. Therefore, the reconcile and post and compress processes are not affected, making version management and replication management independent. This also allows the synchronization schedule to be more flexible.

Since archiving requires the data to be versioned, the source replica must be in an ArcSDE geodatabase. The source replica version must also be the DEFAULT version.

In the diagram below, one-way parent-to-child replication between ArcSDE geodatabases is shown where the DEFAULT version is used as the replica version for both the parent and child. Since file and personal geodatabase types don't support versioning, no replica version is created on the child in the other one-way replica, shown in the diagram.

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