In a bidirectional configuration, SQL changes that are replicated from one system to another must be prevented from being replicated back to the first system. Otherwise, it moves back and forth in an endless loop, as in this example:

1. A user application updates a row on system A.

2. Extract extracts the row on system A and sends it to system B.

3. Replicat updates the row on system B.

4. Extract extracts the row on system B and sends it back to system A.

5. The row is applied on system A (for the second time).

6. This loop continues endlessly.

To prevent data loopback, you may need to provide instructions that:

• prevent the capture of SQL operations that are generated by Replicat, but enable the capture of SQL operations that are generated by business applications if they contain objects that are specified in the Extract parameter file.

• identify local Replicat transactions, in order for the Extract process to ignore them.