How Errors Are Handled
Propagation error handling is specified at the CDDS level; when defining your CDDS you must specify which propagation error mode you want to use. The method the servers use to handle an error detected while transmitting information depends on the error mode.
For all propagation error modes, when a server detects an error it does the following:
• Logs the error, thereby increasing the error count
• Issues e-mail messages to any users on the mail notification list
Note: E-mail error notification is not available on Windows. Using the -NML server flag also turns off error notification. For more information, see the chapter "Using the Replicatior Server."
How Error Modes Affect Server Behavior
Server behavior differs for each propagation error mode.
Note: In the following descriptions, the “current replication transaction” is in the context of the Replicator Server, which can disagree with the original user transaction if the latter updated more than one CDDS.
Error modes and how they affect server behavior are described here:
• Skip Transaction
(Default) The Replicator Server:
– Rolls back the current replication transaction
– Processes the next transaction
– Retries the transaction in error during the next processing of the distribution queue
• Skip Row
The Replicator Server continues from the error with no rollback performed. The record in error is skipped and processing proceeds to the next record. The record in error is removed from the queue.
Note: This setting disables transaction consistency, therefore data integrity needs to be maintained manually.
• Quiet CDDS
The Replicator Server rolls back the current replication transaction. After the rollback of the transaction in error, the Replicator Server quiets the CDDS on the database where the transaction error occurred. (In this context, quiets means disabling propagation from the local database to the target database where the error occurred.)
The Replicator Server continues processing the remaining replicated transactions for the same CDDS on other databases, and for other CDDSs.
For information on reactivating the CDD, see chapter “Using the Replicator Server.”
• Quiet Database
The Replicator Server rolls back the current replication transaction. After the rollback of the transaction in error, the Replicator Server quiets all CDDSs in the database where the transaction error occurred. (In this context, quiets means disabling propagation from the local database to the target database where the error occurred.)
The Replicator Server continues processing the remaining replicated transactions for other databases.
For information on reactivating the database, see chapter “Using the Replicator Server.”
• Quiet Server
The Replicator Server:
– Rolls back the current replication transaction
– Stops processing of the remaining batch of replicated transactions
– Changes its status from active to quiet mode
Last modified date: 01/30/2023