LOG ERRORS failing to capture 2291 errors on UPDATE statement

Question

We are running Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
We have often successfully used the error logging clause when performing batch inserts to the database. However, we now have a situation where an UPDATE statement is failing and rolling back upon encountering a foreign-key referential constraint [ORA-02291]. It is successfully recording Check constraint errors [ORA-02290]. The foreign keys are not deferred, and they have nothing to do with any unique constraints or indices on the table that is the target of the UPDATE statement. The Error-logging table was created by using the DBMS_ERRLOG package. We recreated it to make sure that we had not introduced column format errors. The same problem occurs. The UPDATE statement is attempting to update approximately 12000 rows. Any help in understanding this problem would be appreciated.
Here is the error statement
ORA-02291: integrity constraint (OIFS.FRAME_FK07) violated - parent key not found
Here is the problem statement and its surrounding PLSQL block:
BEGIN <<update_records>>
UPDATE frame f
SET (company_name,
address1_line,
address2_line,
address1_city,
address1_state,
address1_zip,
contact1_name,
contact1_phone_number,
update_date,
update_user,
-- comments,
facility_name,
facility_type,
doing_business_as,
contact1_phone_ext,
contact1_fax,
contact1_email,
contact2_name,
contact2_phone_number,
contact2_phone_ext,
contact2_fax,
contact2_email,
source_survey,
source_status,
address2_city,
address2_state,
address2_zip,
facility_location_number,
attention_line,
company_official,
facility_irs_code
) =
(SELECT company_name,
address1_line,
address2_line,
address1_city,
address1_state,
address1_zip,
contact1_name,
contact1_phone_number,
SYSDATE,
user_in,
facility_name,
facility_type,
doing_business_as,
contact1_phone_ext,
contact1_fax,
contact1_email,
contact2_name,
contact2_phone_number,
contact2_phone_ext,
contact2_fax,
contact2_email,
source_survey,
source_status,
address2_city,
address2_state,
address2_zip,
facility_location_number,
attention_line,
company_official,
facility_irs_code
FROM oifs.respondent r
WHERE r.cin = f.cin
WHERE f.cin IN
(SELECT cin
FROM
(SELECT cin,
company_name,
address1_line,
address2_line,
address1_city,
address1_state,
address1_zip,
contact1_name,
contact1_phone_number,
facility_name,
facility_type,
doing_business_as,
contact1_phone_ext,
contact1_fax,
contact1_email,
contact2_name,
contact2_phone_number,
contact2_phone_ext,
contact2_fax,
contact2_email,
source_survey,
source_status,
address2_city,
address2_state,
address2_zip,
facility_location_number,
attention_line,
company_official,
facility_irs_code
FROM oifs.respondent
MINUS
SELECT cin,
company_name,
address1_line,
address2_line,
address1_city,
address1_state,
address1_zip,
contact1_name,
contact1_phone_number,
facility_name,
facility_type,
doing_business_as,
contact1_phone_ext,
contact1_fax,
contact1_email,
contact2_name,
contact2_phone_number,
contact2_phone_ext,
contact2_fax,
contact2_email,
source_survey,
source_status,
address2_city,
address2_state,
address2_zip,
facility_location_number,
attention_line,
company_official,
facility_irs_code
FROM oifs.frame
LOG ERRORS INTO oifs.frame_load_errors
(job_num || ' ' || TO_CHAR(SYSDATE, 'YYYYMMDD HH24:MI:SS') || ' update')
REJECT LIMIT UNLIMITED;
EXCEPTION
WHEN OTHERS THEN
ohub.err_pkg.record_and_continue(msg_in => 'problem in updating FRAME rows');
RAISE;
END update_records;

Answer 1

Thank you for your help. It pointed me in the right direction, which was to temporarily disable the triggers. The ORA-02291 errors were then properly captured in the error-logging-table.
The problem did not appear to be related to the trigger. The problem that was captured in my PLSQL error-handler but not the error-logging-table was an ORA-02291, which was specific to the original table. The trigger-driven processing did not seem to generate any errors (I have PLSQL error-handling logic in there as well).
I was aware of Tom Kyte's statement, and I knew triggers were dicey when I decided to use them. It seemed the best way to try to ensure database integrity when regular Foreign-Key and Check constraints did not suffice. I am now paying the price for that decision.