Question

I recently started working on a large complex application, and I’ve just been assigned a bug due to this error:

ORA-04091: table SCMA.TBL1 is mutating, trigger/function may not see it ORA-06512: at 'SCMA.TRG_T1_TBL1_COL1', line 4 ORA-04088: error during execution of trigger 'SCMA.TRG_T1_TBL1_COL1' 

The trigger in question looks like

    create or replace TRIGGER TRG_T1_TBL1_COL1    BEFORE  INSERT OR UPDATE OF t1_appnt_evnt_id ON TBL1    FOR EACH ROW    WHEN (NEW.t1_prnt_t1_pk is not  null)    DECLARE         v_reassign_count number(20);    BEGIN        select count(t1_pk) INTO v_reassign_count from TBL1               where  t1_appnt_evnt_id=:new.t1_appnt_evnt_id and t1_prnt_t1_pk is not null;        IF (v_reassign_count > 0) THEN            RAISE_APPLICATION_ERROR(-20013, 'Multiple reassignments not allowed');        END IF;    END; 

The table has a primary key ‘t1_pk‘, an ‘appointment event id’ t1_appnt_evnt_id and another column ‘t1_prnt_t1_pk‘ which may or may not contain another row’s t1_pk.

It appears the trigger is trying to make sure that nobody else with the same t1_appnt_evnt_id has referred to the same one this row is referring to a referral to another row, if this one is referring to another row.

The comment on the bug report from the DBA says ‘remove the trigger, and perform the check in the code’, but unfortunately they have a proprietary code generation framework layered on top of Hibernate, so I can’t even figure out where it actually gets written out, so I’m hoping that there is a way to make this trigger work. Is there?

Answer 1

I think I disagree with your description of what the trigger is trying to do. It looks to me like it is meant to enforce this business rule: For a given value of t1_appnt_event, only one row can have a non-NULL value of t1_prnt_t1_pk at a time. (It doesn’t matter if they have the same value in the second column or not.)

Interestingly, it is defined for UPDATE OF t1_appnt_event but not for the other column, so I think someone could break the rule by updating the second column, unless there is a separate trigger for that column.

There might be a way you could create a function-based index that enforces this rule so you can get rid of the trigger entirely. I came up with one way but it requires some assumptions:

• The table has a numeric primary key
• The primary key and the t1_prnt_t1_pk are both always positive numbers

If these assumptions are true, you could create a function like this:

dev> create or replace function f( a number, b number ) return number deterministic as   2  begin   3    if a is null then return 0-b; else return a; end if;   4  end; 

and an index like this:

CREATE UNIQUE INDEX my_index ON my_table   ( t1_appnt_event, f( t1_prnt_t1_pk, primary_key_column) ); 

So rows where the PMNT column is NULL would appear in the index with the inverse of the primary key as the second value, so they would never conflict with each other. Rows where it is not NULL would use the actual (positive) value of the column. The only way you could get a constraint violation would be if two rows had the same non-NULL values in both columns.

This is perhaps overly ‘clever’, but it might help you get around your problem.

Update from Paul Tomblin: I went with the update to the original idea that igor put in the comments:

 CREATE UNIQUE INDEX cappec_ccip_uniq_idx   ON tbl1 (t1_appnt_event,      CASE WHEN t1_prnt_t1_pk IS NOT NULL THEN 1 ELSE t1_pk END);