Hi,
I read http://download-west.oracle.com/docs...8/conflict.htm with interest and get the concept of what happens with replication and the overwrite scenario.

(Hope I am not breaking any copyright - but this is from the above site)

The description for each type of handler later in this section refers to the following conflict scenario:

1.The following update is made at the dbs1.net source database:

UPDATE hr.employees SET salary = 4900 WHERE employee_id = 200;
COMMIT;

This update changes the salary for employee 200 from 4400 to 4900.
2. At nearly the same time, the following update is made at the dbs2.net destination database:

UPDATE hr.employees SET salary = 5000 WHERE employee_id = 200;
COMMIT;

3. A capture process captures the update at the dbs1.net source database and puts the resulting row LCR in a queue.
4. A propagation propagates the row LCR from the queue at dbs1.net to a queue at dbs2.net.
5. An apply process at dbs2.net attempts to apply the row LCR to the hr.employees table but encounters a conflict because the salary value at dbs2.net is 5000, which does not match the old value for the salary in the row LCR (4400).



So my question is - what prevents the change from being also queued on the OTHER direction, clearly this must happen otherwise the DBs will end up out of synch or thrashing - neither is the case.

So what process / rule says that the LCR from db1 is queued to db2; but the LCR from db2 is not queued to db2.

Cheers,
themanwithno