Pre 10gR2 you are sort of stuck: the MERGE statement is an Atomic operation: it either completes successfully and in its entirety or it fails – again in its entirety. There is no easy way to programmatically and automatically deal with such recordlevel exceptions in statements.

In PL/SQL, you can make use of Bulk DML operations that are actually bundles up packages of individual statements. Those statements can be processed even if one of them fails, using the EXCEPTIONS INTO clause. However, this requires a procedural approach, which is of course what you wanted to avoid in the first place.

I can also think of a simple way to find the offending record in the MERGE statement: create before record and after record insert and update triggers on the table that you are merging into. In the before record trigger, store the ID of the record in a package variable, in the after record trigger you can remove it again (not really necessary by the way). When the statement fails, you will find the identification of the offending record in the package variable. This may help you deal with the problem, by for example running the MERGE statement again, this time excluding the offending record.

You could try to find the offending record

Suppose 100 rows are being processed in Merge. Now 55th row raises an exception. Now I need to commit the previous 54 rows before leaving the block containing the MERGE statement. So I have written an EXCEPTION block but COMMIT is not Working. In addition to, I have also written “PRAGMA AUTONOMOUS_TRANSACTION;” but this is an exercise in futility.

EXCEPTION
WHEN OTHERS THEN
commit;
v_ErrCode := SQLCODE;
v_ErrMsg := SQLERRM;
DBMS_OUTPUT.PUT_LINE(‘Code : ‘||SQLCODE||’ And Error Msg –>> ‘||v_ErrMsg);

If you have time, please help me get the right way to meet the requirement.

Have no idea if all works with MERG command, please lend you advise on the four MERGEs.

Hank