SQL operations are SET operations. When you issue SELECT/UPDATE/INSERT/DELETE... you are not selecting/updating/inserting/deleting individual rows - you are selecting/updating/inserting/deleting SETS. If one row within a set fails - the whole operation fails. Another words SQL is not a procedural language. PL/SQL is - it allows you to work with individual rows. Trigger is written in PL/SQL and is procedural. As a result, we have a conflict. From SQL's point of view operation is done when ALL SET IS PROCESSED while trigger is trying to access table when SET IS PROCESSED YET. So form SQL's point of view table is in "in-between" state. We can not tell what is table contents at the moment. This is called mutating. In "old days" there was also a "constraining table" effect caused by mutation. Assume trigger on a parent table modifies child table. Since parent table is "mutating" Oracle can not validate foreign key. IN 8i constraining issue was removed since checking of the foreign key is deferred until at least the end of the parent statement.

SY.

Oops, made a typo. It should be SET IS NOT PROCESSED YET instead of SET IS PROCESSED YET.

SY