Import a data change message

Available with Standard or Advanced license.

The Import Message geoprocessing tool can import either data change messages or acknowledgment messages. Importing a data change applies data changes from the relative replica and updates the replica's metadata. Importing an acknowledgment updates the replica's metadata so the changes will be included in the next export.

Importing a data change occurs in the following transactions:

• Importing the data
• Reconciling

Necessary resources, 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 complete the reconcile manually later.

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 communication between the replica pair during the data exchange process allow you to determine if a message is late or lost.

To import a data change message, complete the following steps:

1. Access the Import Message tool from one of the following:
   • In the Manage Replicas pane, use either the Replica card or Manage Replicas Menu and click the Import Message button .
   • In the Catalog pane, right-click the geodatabase to which you want to import data changes, point to Distributed Geodatabase, and click Import Message .

   The Import Message tool supports both local and remote geodatabases.

   Note:

   Accessing the Import Message tool automatically populates the Import to Replica Geodatabase parameter based on the current workspace.

2. For Import from Delta file, choose the delta file from which the message will be imported.
3. Optionally, specify a name for the Output Acknowledgment File parameter to create a message that acknowledges the import of a data change message.

   Note:

   The Output Acknowledgment File value must be an XML format file (.xml) type.
4. Optionally, specify how conflicts will be resolved using the Conflict Resolution Policy parameter:

   • IN FAVOR OF DATABASE—The edits of the database importing the changes are used over the edits in the delta file if there is a conflict. Since the conflicts are resolved automatically, the replica is never in a conflict state after importing.

   • IN FAVOR OF IMPORTED CHANGES—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.

   • MANUAL—If a conflict occurs, the reconcile operation stops and the replica is marked as in conflict. This gives you an opportunity to perform the reconcile later, either manually or by running custom reconcile code. Once the reconcile is applied 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.
5. Optionally, for the Conflict Definition parameter, choose how conflicts are defined:
   • BY_OBJECT—Changes to the same row or feature in the target and edit versions are flagged as a conflict.
   • BY_ATTRIBUTE—Only changes to the same attribute (column) of the same row or feature in the target and edit versions are flagged as a conflict.
6. If you are using a checkout replica, you can use the Reconcile with the Parent Version parameter to automatically reconcile once the message is imported.