Available with Standard or Advanced license.
The three types of geodatabase replication are checkout/check-in, one-way, and two-way. Each is described below.
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.
The parent replica is always an enterprise geodatabase. The child replica can be either an enterprise or file geodatabase.
Once you synchronize the data, the checkout replica is unregistered (deleted), and you can no longer synchronize additional edits. If additional edits are required, you must create another checkout replica.
One-way replication
One-way replication allows data changes to be sent multiple times in a single direction, from parent to child replica or from child to parent replica. One-way replicas persist after synchronization, allowing you to continue sending data changes.
- 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, the edits are overwritten if they conflict with edits applied during synchronization. When creating a one-way, parent-to-child replica, the source (parent) replica is always an enterprise geodatabase; the destination (child) can be an enterprise or file geodatabase.
- One-way, child-to-parent replication—This 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 replica 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 enterprise geodatabase.
Two-way replication
Two-way replication allows data changes to be sent multiple times from the parent replica to the child replica and 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.
Tip:
You can configure the conflict resolution policy and define what constitutes a conflict when you synchronize to control 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 source (parent) and destination (child) must be an enterprise geodatabase.
Choose a replica type
When deciding which replica type to use, consider the following:
- If you require the ability to create replicas in file geodatabases, you must use either checkout/check-in or one-way replication.
- Two-way replication allows you to synchronize multiple times without having to re-create replicas. This replica type requires an enterprise geodatabase for the source and destination geodatabases.
- One-way replication is ideal for cases when you want to publish changes from your production server to your publication server. See Distributed data scenarios for a description of this workflow.
One-way replication enforces unidirectional synchronization and doesn't require the child replica's data to be versioned if you use the simple replica access type model. With a simple model, the features and their attributes are included in the replica but extended geodatabase functionality is not. This makes the data more interoperable, because it doesn't have to conform to complex geodatabase data structures.
- If you sometimes need to edit the child replica's data, use two-way replication. Because one-way replication assumes that the data is read-only on the child replica, synchronizing 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 if you opt to resolve conflicts manually. Two-way replication allows data exchange in both directions but also works in cases when you only send changes in one direction.
The following table summarizes the different geodatabase replication types:
| Child replica is stored in a file geodatabase | Supports multiple syncs before unregistering | Can sync updates in both directions | |
|---|---|---|---|
Checkout/check-in to a file geodatabase |  | ||
Checkout/check-in to enterprise geodatabase | |||
One-way to file geodatabase (Parent - Child) | | | |
One-way to enterprise geodatabase (Parent - Child) | | ||
One-way to enterprise geodatabase (Child - Parent) | | ||
Two-way to enterprise geodatabase | | |