A modification to primary data may fail to update a copy of the data at a subscribing site. The primary version is the “official” copy and updates that succeed there are expected to succeed at subscribing sites with copies.
If the updates do not succeed, one of the following reasons may explain why:
Replicate and primary versions are out of sync following a system recovery and a loss has been detected.
See Chapter 7, “Replication System Recovery” in the Replication Server Administration Guide Volume 2 for more information.
The data server storing the copy of the table has constraints that are not enforced by the data server storing the primary version.
The data server storing the copy of the table rejects the transaction due to a system failure, such as lack of space in the database or a full transaction log.
When a transaction fails, Replication Server records the transaction in an exceptions log for handling that is appropriate to the application. Replication Server offers error handling flexibility through its error action feature. This feature allows responses to data server errors based on your own defined configuration settings. For example, you can specify that transactions be retried at the site where they failed.
A client at each site must resolve transactions in the exceptions log, because the appropriate resolution is application-dependent. In some cases, you can automate the resolution by encapsulating the logic for handling rejected transactions in an intelligent application program.
