A modification to primary data may fail to update a replicate copy of the data at another site. The primary version is the “official” copy, and updates that succeed at the primary database are expected to succeed at sites with replicate copies.
Some reasons for the failure of an update to a replicated table are:
The data server’s maintenance user login name does not have the permissions needed to update the replicate data.
The replicate and primary versions of the data are inconsistent after a system recovery.
A client updates replicate data directly rather than updating the primary version.
The data server storing the replicate table has constraints that are not enforced by the data server storing the primary version.
The data server storing the replicated copy of the table rejects the transaction due to a system failure, such as lack of space in the database.
When a transaction fails, Replication Server receives an error from the data server. Data server errors are mapped to Replication Server error actions. The default action for a failed transaction is to write a message in the Replication Server error log (including the message returned by the data server) and then suspend the database connection. After you correct the cause of the failure, you can resume the database connection and Replication Server will retry the failed transaction.
You also can have Replication Server record a failed transaction in the exceptions log (a set of three tables in the RSSD) and continue processing the next transaction. Refer to “Replication Server” for a description of the RSSD.
If you use the exceptions log, you must manually resolve the transactions that are saved there to make the replicate data consistent with the primary data. In some cases, the process can be automatic by encapsulating the logic for handling the rejected transactions in an intelligent application program.
