The way each Replicator Server detects, handles, and notifies you of errors depends on the error mode of the CDDS. For more information, see How Errors Are Handled on page 51.

Error handling also depends on flag settings that you can change while the server is running.

A server detects errors in these categories:

If the runrepl.opt file settings are invalid or inconsistent, the server logs the error, changes the offending flag to the default setting, and continues. If the runrepl.opt file settings are incomplete, that is, required options are missing, the server shuts down.

You can specify whether to bypass the unique key check on the replicated tables when the server first connects to a database.

If primary key checking is enabled, Replicator Server checks for unique keys for the tables assigned to it on the local and remote databases to which it transmits. If key checking discovers an error on the local database, the server is shut down. If an error is found when checking a remote database, the target is quieted.

The primary key-checking options are:

DBMS server errors include timeout, deadlock, and log file full errors. If a DBMS server error occurs during the transmission of data or the distribution of queue information, the servers increase the error count, issue a mail message to those users listed in the Mail Notification List, and retry the transaction.

DBMS server timeout means that database resources are currently unavailable and require a retry. During the retry, the server rolls back the current transaction and re-attempts the timed-out transaction.

If errors other than a DBMS server timeout occur during the transmission of data, the server performs the action as determined by the error code of the CDDS. For more information, see How Errors Are Handled on page 51.