ArcGIS Server Banner

Replication types (ArcInfo and ArcEditor only)

Replication types (ArcInfo and ArcEditor only)
Release 9.3

Three types of geodatabase replication are provided. 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 child replica's data and then 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 ArcCatalog and ArcMap 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 from the parent replica to the child replica. Changes cannot be sent from the child replica to the parent replica. Here the parent replica's data is editable, but the data on the child is considered read-only. If edits are performed on the child replica's data, they will be overwritten if they conflict with edits applied during synchronization. Conflicts are not reported when synchronizing with one-way replicas. One-way replicas continue to exist after synchronization, allowing you to continue sending data changes from the parent replica to the child replica. When creating one-way replicas, the destination may be an ArcSDE geodatabase, a file geodatabase, or a personal geodatabase.

One-way replicas can use either a full or a simple model type:

Full—The full model supports complex types (topologies and geometric networks) and requires the child replica's data to be versioned.

Simple—With a simple model, the child replica's data is created as simple types and is not registered as versioned. Therefore, geometric networks or topologies from the source geodatabase are not created on the destination geodatabase.

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 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 may overwrite edits to the child replica's data. The conflict detection logic of two-way replication will flag 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.

See Also

Preparing data for replication

About synchronization

Creating replicas

Synchronizing connected replicas

Synchronizing disconnected replicas

Please visit the Feedback page to comment or give suggestions on ArcGIS Server Help.
Copyright © Environmental Systems Research Institute, Inc.