Replica creation and versioning (ArcInfo and ArcEditor only)
Replica creation and versioning (ArcInfo and ArcEditor only)
|
| Release 9.3 |
   |
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 replica. Several replicas can also share the same replica version. See Creating replicas to see how to set the replica version for the parent.
The default version is used as the replica version on the child for two-way replicas. This is also the case for one-way replicas when the child of the one-way replica is hosted in an ArcSDE geodatabase.
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.
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. Here, additional logic is used to determine the changes to send during synchronization.
For checkout replicas, 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. Here, 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.
