You can use the Synchronize Changes geoprocessing tool within ArcGIS Pro to synchronize updates between two replica geodatabases in a direction specified by the user. This topic describes the input parameters for this tool and reviews several options that are important to understand.
The Synchronize Changes tool provides the following options:
Input geodatabases and replica
- Geodatabase 1: The geodatabase hosting the replica to synchronize. The geodatabase may be local or may reference a geodata service on your ArcGIS Server. The Synchronize Changes tool will attempt to autofill the parameters based on default settings and information stored in the replica. When the Synchronize Changes tool is launched from the Menu button
on the Manage Replicas pane or the Distributed Geodatabase context menu, geodatabase 1 will contain the connection information from the current workspace. The replica parameter is populated with the first replica that is found in the workspace. If Synchronize Changes is launched from the card, the replica parameter gets the name of the replica for that card.Note:
You can publish a geodatabase to ArcGIS Server as a geodata service from ArcMap only. These geodata services can be used with replication in ArcGIS Pro as a geodatabase parameter.
- Replica - A valid replica with a parent contained within one input geodatabase and a child in the other input geodatabase
- Geodatabase 2 - The geodatabase hosting the relative replica. The geodatabase may be local or may reference a geodata service on your ArcGIS Server. In addition, for geodatabase 2, if the relative replica connection information is stored in the replica properties of the current replica, the tool will either search for a matching connection file or construct a temporary connection file based on the information stored in the replica. Geodatabase 2 will then be populated with this information after which the connection will be validated to see if it is reachable. If it is not reachable, geodatabase 2 will be invalidated and the user would have to correct the information.
Direction
When synchronizing changes, you can choose the direction in which you want the changes to be sent.
For two-way replicas, any of the three choices are available: you can send changes to the relative replica, get changes from the relative replica, or move changes in both directions. If you choose both directions, changes are first sent in one direction and then sent in the opposite direction, in a single operation.
For one-way replicas, only the option to send changes in one direction is available, either from parent to child or from child to parent. For checkout/check-in replicas, only the option to send changes from the child replica to the parent replica is available.
- Both Directions - Changes will be synchronized in both directions. This is the default for two-way replicas.
- From geodatabase 1 to geodatabase 2 - Changes will be synchronized from geodatabase 1 to geodatabase 2.
- From geodatabase 2 to geodatabase 1 - Changes will be synchronized from geodatabase 2 to geodatabase 1.
Conflict Resolution Policy
During synchronization, a reconcile and post may occur between the synchronization version and the replica version. During this reconcile process, conflicts may occur. You can choose a reconcile policy to define how to handle these conflicts when they are encountered. For information on synchronization versions, replica versions, and when reconcile occurs, see Synchronization and versioning.
Conflict resolution policies include the following:
- Manual - With this policy, if a conflict occurs, the reconcile operation is aborted, and the replica is marked as in conflict
. This gives you an opportunity to perform the reconcile operation afterward either manually or by running some custom reconcile code. Once the reconcile is completed and the changes are posted to the replica version, the replica is no longer in conflict. While the replica is in conflict, it can continue to receive changes but cannot send changes.
To learn more, see Resolve synchronization conflicts manually.
- Resolve in favor of geodatabase 1 - Conflicts resolve in favor of Geodatabase 1. In this case, the representation in geodatabase 1 is automatically used over the representation in geodatabase 2 if there is a conflict. Since the conflicts are resolved automatically, the replica is never in a conflict state after synchronizing with this policy.
- Resolve in favor of geodatabase 2 - Conflicts resolve in favor of Geodatabase 2. In this case, the representation in geodatabase 2 is automatically used over the representation in geodatabase 1 if there is a conflict. Since the conflicts are resolved automatically, the replica is never in a conflict state after synchronizing with this policy.
Note:
The default policy is for the parent replica's representation to be used. This can be either in favor of geodatabase 1 or in favor of geodatabase 2, depending on which one contains the parent replica.
For two-way replication, if you choose to synchronize in both directions, you cannot choose a manual reconcile policy.
Conflict Definition
- Conflicts defined by row - Detects conflicts by object.
- Conflicts defined by column - Detects conflicts by attribute.
Reconcile with the Parent Version
This option is only available with checkout/check-in replicas and indicates whether to automatically reconcile once data changes are sent to the parent replica if there are no conflicts present.
- Do not reconcile - Do not reconcile. This is the default.
- Reconcile - Automatically reconcile.
Learn more about reconciling a version.
Note:
The import phase of the synchronization process occurs within a transaction. The second phase of a synchronization includes a reconcile, which also occurs in a transaction. Resources needed, such as undo space or logical log files, will vary with the number of changes to be synchronized. If the import phase completes but the reconcile phase returns an error, the replica will appear as if in conflict , and you can later complete the reconcile manually.
Error handling
If an error occurs during synchronization, the operation is rolled back. Any changes that have been applied are removed, and the system is placed back into a state as it was before the synchronization.
An exception to this rule can occur when you synchronize in both directions. Here, if an error occurs after the process of applying changes in one direction completes, these changes are committed; however, the system is still in a consistent state, and further synchronizations are not affected.