Replication types
This topic applies to ArcEditor and ArcInfo only.
The three types of geodatabase replication are: check out/check in, one way, and two way.
For all types, data from an ArcSDE geodatabase must be used as the source for replica creation. All types are also supported in either connected or disconnected environments. The following describes each of these types:
Checkout/Check-in replication
Checkout/Check-in replication allows you to edit the data in the child replica and synchronize these edits with the parent replica.
Once the data has been synchronized, you can no longer synchronize additional edits. If additional edits are required, you must create a new checkout replica. When creating checkout replicas, the destination can be either an ArcSDE, file, or personal geodatabase.
Disconnected editing, which was first available in ArcGIS 8.3, is now part of geodatabase replication and is equivalent to checkout/check-in replication. The disconnected editing tools that were available in ArcGIS Desktop have been removed and are now part of the distributed geodatabases framework. The disconnected editing geoprocessing tools, however, are still available for backward compatibility.
One-way replication
One-way replication allows data changes to be sent multiple times in a single direction, either from parent to child or from child to parent.
In one-way, parent-to-child replication, the data in the parent replica is editable, but the data in the child is considered read-only. If edits are performed on the data in the child replica data, the edits are overwritten if they conflict with edits applied during synchronization.
When creating a one-way, parent-to-child replica, the destination can be an ArcSDE, file, or personal geodatabase.
One-way, child-to-parent replication works in a similar manner, but in the opposite direction. Here the data in the child replica is editable, but the data in the parent is considered read-only. If edits are performed on the data in the parent replica, the edits are overwritten if they conflict with edits applied during synchronization.
When creating a one-way, child-to-parent replica, both child and parent replicas must be hosted in an ArcSDE geodatabase.
One-way replicas persist after synchronization, allowing you to continue sending data changes.
Two-way replication
Two-way replication allows data changes to be sent multiple times from the parent replica to the child replica or from the child replica to the parent replica. If the same row is edited in both replica geodatabases, it is detected as a conflict when the replicas are synchronized. Reconcile policies are provided to define how conflicts are processed.
Two-way replicas continue to exist after synchronization, allowing you to continue editing and synchronizing the replicas. When creating two-way replicas, the destination must be an ArcSDE geodatabase.
Choosing a replica type
When deciding which replica type to use, consider the following:
- If you require the ability to create replicas in personal or file geodatabases, you must use either checkout/check-in or one-way replication. However, if you are using an ArcEditor license to edit the child replica's data, consider using personal ArcSDE as the target geodatabase. Using personal ArcSDE instead of your personal or file geodatabases allows you to create two-way replicas. With two-way replication, you can synchronize multiple times without have to re-create the replicas.
- One-way replication is ideal for cases where you want to publish changes from your production server to your publication server. One-way replication enforces unidirectional synchronization and doesn't require the child replica's data to be versioned if using the simple model. With a simple model, the fact that the types are simple makes the data more interoperable since it doesn't have to conform to complex ESRI data structures.
- If implementing a one-way system where you sometimes need to edit the child replica's data, consider using two-way replication. Since one-way replication assumes that the data is read-only on the child, a synchronization might overwrite edits to the child replica's data. The conflict detection logic of two-way replication flags these differences as conflicts, allowing you to decide how to handle the differences. Two-way replication allows data exchange in both directions but also works in cases where you only send changes in one direction.