Importing a data change message

The Import Message wizard can import either data change messages or acknowledgment messages. Importing a data change applies data changes from the relative replica and also updates the replica's metadata. Importing an acknowledgment updates a replica's metadata such that it knows what changes to include in the next export.

Importing a data change occurs in two transactions: importing the actual data and reconciling. Resources needed, such as undo space or logical log files, vary with the amount of changes to be synchronized. If the import completes but the reconcile results in an error, the replica will appear as if in conflict, and you can later go in and complete the reconcile manually.

It is recommended that the receiver send an acknowledgment after a data change is imported so that the data sender knows the data was received. This keeps good communication between the replica pair during the data exchange process and makes it easier to tell if a message is late or has been lost.

Tip:

You can also use the Import Message geoprocessing tool. See Import Message for more information.

Steps:

1. The Import Message wizard can be opened from the Distributed Geodatabase toolbar or from the context menu of the geodatabase or geodata service.
   • In ArcMap, open the Distributed Geodatabase toolbar and click the Import Message button.
   • In the Catalog window, right-click the geodatabase or geodata service published through ArcGIS for Server into which you want to import a message, point to Distributed Geodatabase, then click Import Message.

   The wizard supports both local and remote geodatabases. Remote geodatabases are accessed in ArcMap through map services that have the geodata access capability enabled.

2. Choose the replica geodatabase you want to import a message to.
3. Choose the delta file you would like to import.
4. If you are using a checkout replica, you have the option to reconcile with the parent version once the message is imported.
5. Choose between column- and row-level conflict detection.
6. Choose how to resolve conflicts:

   • In favor of the database—In this case, the edits of the database importing the changes are used over the edits in the delta file is there is a conflict. Since the conflicts are resolved automatically, the replica is never in a conflict state after importing with this policy.

   • In favor of the imported changes—Here, the edits defined in the delta file are used over the edits of the database importing the changes if there is a conflict. Since the conflicts are resolved automatically, the replica is never in a conflict state after importing with this policy.

   • Manually at a later time—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 afterwards, either manually or by running some custom reconcile code. Once the reconcile is applied and the changes 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.