Available with Standard or Advanced license.
You can use the Synchronize Changes geoprocessing tool in ArcGIS Pro to synchronize updates between two replica geodatabases in the direction that you specify.
The tool's input parameters and options are explained below to help you understand how each setting affects the synchronization process.
Input geodatabases and replica
Define which geodatabases or geodata services contain the related replicas to synchronize and in what direction the changes will be sent when synchronizing.
You'll designate one geodatabase or geodata service as geodatabase 1 and the other as geodatabase 2. This allows you to subsequently define the direction that changes will be sent during synchronization and how conflicting changes should be resolved, if you choose to automatically resolve conflicts.
Note:
Ensure that the geodata services you specify use the ArcGIS Pro service runtime, because the ArcMap service runtime is no longer supported. See Services and the ArcGIS Pro service runtime for information about service runtimes and how to migrate a geodata service.
- Geodatabase 1—A file geodatabase, enterprise geodatabase, or geodata service that contains the replica to synchronize.
If you launch the Synchronize Changes tool from the Menu button
in the Manage Replicas pane or the Distributed Geodatabase context menu, Geodatabase 1 will contain the connection information from the current workspace. - Replica—A valid replica with a parent contained in one input geodatabase and a child in the other input geodatabase. The replica parameter is populated with the first replica found in the workspace for Geodatabase 1, but you can choose a different replica.
If you open the Synchronize Changes tool from a specific geodatabase replica in the Manage Replicas pane, the replica parameter is populated with the name of that replica.
- Geodatabase 2—A file geodatabase, enterprise geodatabase, or geodata service containing the replica related to the replica in Geodatabase 1.
The Synchronize Changes tool reads the relative replica information stored with the Geodatabase 1 replica and uses this information to populate the Geodatabase 2 parameter. If this fails, the Geodatabase 2 parameter value is marked invalid in the tool, and you must correct the problem before proceeding.
The following are a few examples of why the tool cannot access the geodatabase:
- The machine where you're running the tool doesn't have access to the folder where the file geodatabase is stored.
- The enterprise geodatabase connection is no longer valid because the connecting user's password has changed or the license stored in the geodatabase has expired.
- The file geodatabase was deleted.
- The geodata service does not exist on the server.
Direction
Now that you defined the geodatabases or geodata services that contain the related replicas, choose the direction that changes will be sent.
For two-way replicas, you can use any of the options below.
For one-way replicas, you can synchronize from geodatabase 1 to geodatabase 2 or from geodatabase 2 to geodatabase 1.
For checkout/check-in replicas, only the option to send changes from the child replica to the parent replica is available. The tool determines which geodatabase or geodata service is the child and sets the direction accordingly; you cannot change it.
- 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.
- Both directions—Changes are first sent in one direction and then sent in the opposite direction. This is the default setting for two-way replicas.
Conflict resolution policy
When you synchronize replicas, a reconcile and post process may occur between the synchronization version and the replica version. During this reconcile process, conflicts may occur. You can choose a policy that defines how to handle these conflicts.
For information on synchronization versions, replica versions, and when the reconcile process occurs, see Synchronization and versioning.
Choose one of the following conflict resolution policies:
- Manually resolve conflicts—With this policy, the reconcile operation stops when a conflict occurs, and the replica is marked to indicate that it contains conflicts
. This allows you to perform the reconcile operation afterward, either manually or by running custom reconcile code, so you can evaluate conflicts individually. Once you complete the reconcile process and post changes to the replica version, the replica no longer contains conflicts.
To learn more, see Resolve synchronization conflicts manually.
Note:
While the replica contains synchronization conflicts, it can continue to receive changes but cannot send changes.
For two-way replication, if you choose to synchronize in both directions, you cannot choose a manual conflict resolution policy.
- Resolve in favor of geodatabase 1—The representation in geodatabase 1 is automatically used over the representation in geodatabase 2 if there is a conflict. Because conflicts are resolved automatically, the replica is never in a conflict state after synchronizing with this policy.
- Resolve in favor of geodatabase 2—The representation in geodatabase 2 is automatically used over the representation in geodatabase 1 if there is a conflict. Because conflicts are resolved automatically, the replica is never in a conflict state after synchronizing with this policy.
Conflict definition
As mentioned in the previous section, conflicts can occur during the reconcile process that takes place when you synchronize.
For information about the reconcile process and options, see Versioning options.
Choose one of the following options to define what type of change is considered a conflict:
- Conflicts defined by row—If the same feature or row changes in both versions, it is identified as a conflict.
- Conflicts defined by column—If a change to the same attribute or the geometry of the feature class changes in both versions, it is identified as a conflict.
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—The reconcile process will not take place. This is the default.
- Reconcile—Automatically reconcile.
Learn more about how to reconcile and post edits to a traditional version
Note:
The import phase of the synchronization process occurs within a transaction. The second phase of a synchronization includes a reconcile process, which also occurs in a transaction. Resources needed, such as undo space or logical log files, 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 it is in conflict , and you can later complete the reconcile process manually.
Error handling
If an error occurs during synchronization, the operation is rolled back. Any changes that were applied are removed, and the system is placed back into the state it was in before changes were synchronized.
An exception to this 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 synchronization processes are not affected.