The problem occurs when an attempt is made to delete a row that is referenced by a foreign key. The foreign key constraint requires that the parent record always exist for a child record and that the parent record cannot be deleted unless the child record is deleted first.
The error can be ignored by configuring the oramsglist file and the parameter SP_OPO_CONT_ON_ERR. The way to do it is:
1. With Post stopped, go to vardir/data and edit ogamsglist file.
2. Increment the number (2 digit number) on the first line by one.
3. Add a new line at end of the oramsglist by inserting the number 2292 which corresponds to ORA-02292.
4. Save the file and exit
5. Go to sp_ctl and activate this paramter to tell Post to ignore the error.
sp_ctrl> set param SP_OPO_CONT_ON_ERR 1
sp_ctrl> activate param
sp_crl> start post
When you by-pass this error, undo the changes done above, namely decrement the oramsglist error count, remove the error, save file and set the SP_OPO_CONT_ON_ERR back to 0 similarly as above. However, this can cause out of sync as any record that is causing the constraint to fail may be thrown away.
Another way to address it is to disable the integrity constraints on the target as they are validated on the source and then start Post. This will keep posting records on target without validating the referential integrity of the data with the assumption that the data has already been validated on source.
Some of the reasons that can cause this error are:
1. Using named Post queues and routing parent and child tables through separate named queues.
2. DML on target by users other than splex user.
3. Disabling the foreign key constraint on source to make a transaction succeed and then enabling it with NOVALIDATE. While the constraint is disabled, one can sync the source and target table using compare with repair and then re-enable the constraint.
4. Any trigger modifying any of these related tables on the target causing the failure in applying the data from the queue.
5. The source and target tables may not have been in sync to start with.
6. Disabling the constraints on target and re-enabling them with NOVALIDATE option.
7. ON DELETE CASCADE constraint enabled on any of these tables on target.
8. Duplicate entries for the tables in the config file
One side note. If any of the parent or child tables are very large, the out of sync introduced by the above remedy can be extremely painful to correct. Hence it is advisable that users have procedures in place to avoid this type of error creeping into the system.
