Question

My issue is that the trigger detailed below seems to execute correctly except for the fact that the update statement UPDATE my_dblist
SET passive_servername = v_newpassive WHERE server = :NEW.server AND dbname = :NEW.dbname; does not seem to happen. The old record is deleted and inserted into history correctly but the new record does not have the old active server listed under passive_servername. I have a feeling this might have something to do with it being autonomous?

create or replace
TRIGGER cluster_check
AFTER INSERT ON my_dblist
FOR EACH ROW
DECLARE
pragma autonomous_transaction;
v_duplicates NUMBER;
v_newpassive varchar2(30);
BEGIN
SELECT count(*) INTO v_duplicates FROM my_dblist WHERE passive_servername         = :new.server and dbname = :new.dbname order by 1;
IF v_duplicates > 0
THEN 
SELECT server INTO v_newpassive FROM my_dblist WHERE passive_servername = :NEW.server AND dbname = :NEW.dbname ORDER BY 1;
UPDATE my_dblist
SET passive_servername = v_newpassive WHERE server = :NEW.server AND dbname = :NEW.dbname;
INSERT INTO my_dblist_history 
SELECT * FROM my_dblist WHERE passive_Servername = :NEW.server AND dbname = :NEW.dbname;
DELETE FROM my_dblist 
WHERE passive_Servername = :NEW.server AND dbname = :NEW.dbname;
END IF;
commit;
END;

Answer 1

Your trigger is declared to use an autonomous transaction. That is almost always an error unless the sole purpose of the trigger is to log an attempt to change a row of data that you want to persist whether or not the change is ultimately successfully committed. In this case, it is also likely to be the source of your problem. Since the trigger is an autonomous transaction, it cannot see the uncommitted changes made by the triggering statement. Your UPDATE statement, for example, will not see the row(s) that caused the trigger to be fired because those rows are, by definition, uncommitted work done in a different transaction.

Can you take a step back and explain exactly what problem you are trying to solve? I’m assuming that you are attempting to use an autonomous transaction to work around a mutating table exception. That is almost always a mistake. A mutating table exception almost universally indicates that you have a data model problem so you are much better served fixing the data model than working around the error. If you cannot correct the data model, you’ll need to use multiple triggers to work around the mutating table error.