Async replication guru advice wanted....

Has anybody had problems with application triggers interfering with the replication process resulting in lost transactions or invalid 'old' values causing the some update statements to fail with -1403. (Note: there is a known Replication bug whereby the RPC update statement produces the -1403 error code erroneously. But in my case the update statement correctly fails because the data is wrong, (i.e. got out of sync somehow) - even though everything was sync'ed and normalised before the test ran. (I posted this same problem 1 month ago but no replies)

I will briefly describe our setup:
- Master definition site is 7.3.3

• Three destination site (1 x 7.3.2) & (2 x 7.4)
• Oracle Replication Manager 1.3.5

Two master groups MG1 and MG2. MG1 goes to all three destinations and MG2 goes to the 7.4 sites.

Replication triggers (...$RT) have been turned off on the destination sites.

On the destination databases, application triggers have been placed on the replicated objects. These AFTER EACH ROW triggers acquire data from incoming deferred transactions applied to replicated tables and maintain a separate set of tables in another schema. We can prove that the data is getting screwed because we have a before row triger on each destination table which 'tees' off data images to a log file. The log files differ even though each destination is sent the exact same data.

I can't reproduce the error. It happens intermittently. However by removing the application triggers the problem doesn't seem to reappear. A different application team developed each set of triggers. My set is heavily package/procedure based and the other is not. Both have extensive error handling with the WHEN OTHERS exception being handled in every case.

HELP!!!! Liam Received on Mon Aug 24 1998 - 06:20:51 CDT