The transaction error mode options (see the table below) set the actions to take if an error occurs during application of a transaction to the target table (and the error does not cause a lost connection to the target host). These options take effect if you disable all collision resolution or if you select the manual option for protected resolution. If you select the manual option, it is essential that the transaction error mode be compatible with manual resolution.
Set the transaction error mode on the Replication tab of the Replication Request Properties dialog box:
|
Option |
Effect |
|---|---|
|
Rollback current, continue with next |
Rolls back the current replication transaction; proceeds to its next transaction. |
|
Ignore, delete from queue, and continue |
Continues processing despite the error. The statement and record that caused the error are copied to the log and deleted from the queue tables. Note: Do not select this option if you are manually processing collisions on protected tables. |
|
Shutdown, apply component |
Rolls back the current transaction, shuts down all connections, and shuts down the Applier. The sending server’s queue tables remain in the state that the last successful transaction left them. |
Unprotected collision resolution is a low-overhead alternative to protected resolution, since it does not use shadow tables, relying instead on the detection of collisions by their error codes.
An example of a type of collision that unprotected resolution fails to detect and correct is a “simultaneous update” collision: a row in a source table and its corresponding target row and table are changed by the same kind of SQL update by users at nearly the same moment. If the tables are protected, shadow table records reveal the unexpectedly later timestamp at the target. If unprotected resolution is in effect, the collision is not detected because there is no SQL error.