The system also allows replicas to resend unacknowledged data changes. You may want do this when, as a data sender, you either know or suspect that an earlier data change message has been lost and needs to be re-sent. Another option is to wait until the next time you send data changes, since by default this includes both new changes and any unacknowledged changes.

The diagram below shows a case where you need to resend unacknowledged data changes. Here, the parent sends a data change message and switches from sender to receiver. The message, however, gets lost, leaving both the parent and the child as data receivers. To solve this issue, the option to reexport unacknowledged messages is available to the data receiver that has just switched roles. In this case, it allows the parent to resend the message to switch roles to the child.

After switching roles, the option to export an acknowledgment message is available for the data sender to acknowledge the message that switched the roles. Another option is to send a data change message since it will implicitly acknowledge this message. If you don't plan on sending a data change message in the near future, however, you may want to send an acknowledgment message.

In the diagram below, the parent sends a data change message that switches roles. When the child receives the message, it becomes a data sender, but since it has just switched, the system still allows it to send an acknowledgment message.

It is possible to send a data change message with instructions to switch roles but without any data changes. You may want to do this if, as the data sender, you need to get changes from the data receiver but are not ready to send data changes. See Synchronizing disconnected replicas to find out how to send a data changes message with only instructions to switch roles.

When sending data changes, all new data changes and unacknowledged data changes are sent by default. New changes are any inserts, updates, and deletes applied to the replica version since the last data change message was exported. Unacknowledged data changes include previously exported changes for which you have not received an acknowledgment. If you have sent several data change messages for which you have not received an acknowledgment, the messages can become large.

The best solution is for the data receiver to send an acknowledgment message. However, depending on the communication system, this can be difficult.

An alternative is to use verbal acknowledgment. In this situation, the sender gets a verbal acknowledgment from the person managing the data receiver that changes sent previously have been received. You can use the replica manager to determine what changes have been sent and received by a replica. The data sender then sends only new changes (see Synchronizing disconnected replicas to find out how). These can be imported by the data receiver as long as it was correctly reported that changes sent previously have been received. If the system detects that changes sent previously have not been imported, it will result in an error. If several data change messages are sent at once, they must be imported in the correct order. The system will result in an error if you attempt to import in an incorrect order.

When errors occur, error messages are provided. However, if using an automated system, you may not be present to see the errors. In this case, you can use the replica log to detect if errors have occurred during synchronization. The log also provides instructions on how to recover when appropriate.

It is important to note that although the messages will be smaller, the verbal acknowledgment approach is not equivalent to using acknowledgment messages. Importing acknowledgment messages is the only way for the system to drop system versions required to resend changes for a replica. These system versions can hinder compression over time and make the sender's geodatabase large. For this reason, it is still important to periodically use acknowledgment messages even when using the verbal acknowledgment approach.