РТЫ 04091: таблица [вздор] видоизменяется, триггер/функция не может видеть его

Я соглашаюсь с Dave, что желаемый результат, вероятно, может и должен быть достигнут с помощью встроенных ограничений, таких как уникальные индексы (или ограничения на уникальность данных).

Если действительно необходимо обойти видоизменяющуюся ошибку таблицы, обычный способ сделать это состоит в том, чтобы создать пакет, который содержит ограниченную по объему пакетом переменную, которая является таблицей чего-то, что может использоваться для идентификации измененных строк (я думаю, что ROWID возможен, иначе необходимо использовать PK, я в настоящее время не использую Oracle, таким образом, я не могу протестировать его). ДЛЯ КАЖДОГО триггера СТРОКИ затем заполняет эту переменную со всеми строками, которые изменяются оператором, и затем существует ПОСЛЕ каждого триггера оператора, который читает строки, и проверьте их.

Что-то как (синтаксис является, вероятно, неправильным, я не работал с Oracle в течение нескольких лет),

CREATE OR REPLACE PACKAGE trigger_pkg;
   PROCEDURE before_stmt_trigger;
   PROCEDURE for_each_row_trigger(row IN ROWID);
   PROCEDURE after_stmt_trigger;
END trigger_pkg;

CREATE OR REPLACE PACKAGE BODY trigger_pkg AS
   TYPE rowid_tbl IS TABLE OF(ROWID);
   modified_rows rowid_tbl;

   PROCEDURE before_stmt_trigger IS
   BEGIN
      modified_rows := rowid_tbl();
   END before_each_stmt_trigger;

   PROCEDURE for_each_row_trigger(row IN ROWID) IS
   BEGIN
      modified_rows(modified_rows.COUNT) = row;
   END for_each_row_trigger;

   PROCEDURE after_stmt_trigger IS
   BEGIN
      FOR i IN 1 .. modified_rows.COUNT LOOP
         SELECT ... INTO ... FROM the_table WHERE rowid = modified_rows(i);
         -- do whatever you want to
      END LOOP;
   END after_each_stmt_trigger;
END trigger_pkg;

CREATE OR REPLACE TRIGGER before_stmt_trigger BEFORE INSERT OR UPDATE ON mytable AS
BEGIN
   trigger_pkg.before_stmt_trigger;
END;

CREATE OR REPLACE TRIGGER after_stmt_trigger AFTER INSERT OR UPDATE ON mytable AS
BEGIN
   trigger_pkg.after_stmt_trigger;
END;

CREATE OR REPLACE TRIGGER for_each_row_trigger
BEFORE INSERT OR UPDATE ON mytable
WHEN (new.mycolumn IS NOT NULL) AS
BEGIN
   trigger_pkg.for_each_row_trigger(:new.rowid);
END;

С любым основанным на триггере (или основанный на коде приложения) решение необходимо вставить блокировку для предотвращения повреждения данных в пользовательской среде. Даже если бы Ваш триггер работал или был переписан для предотвращения видоизменяющейся проблемы таблицы, то он не предотвратил бы 2 пользователей от одновременного обновления t1_appnt_evnt_id к тому же значению на строках, где t1_appnt_evnt_id не является пустым: предположите, что нет currenly никаких строк, где t1_appnt_evnt_id=123 и t1_prnt_t1_pk не являются пустыми:

Session 1> update tbl1 
           set t1_appnt_evnt_id=123 
           where t1_prnt_t1_pk =456;
           /* OK, trigger sees count of 0 */

Session 2> update tbl1
           set t1_appnt_evnt_id=123
           where t1_prnt_t1_pk =789;
           /* OK, trigger sees count of 0 because 
              session 1 hasn't committed yet */

Session 1> commit;

Session 2> commit;

У Вас теперь есть поврежденная база данных!

Способ избежать этого (в триггере или коде приложения) состоял бы в том, чтобы заблокировать родительскую строку в таблице, на которую ссылается t1_appnt_evnt_id=123 прежде, чем выполнить проверку:

select appe_id 
into   v_app_id
from parent_table
where appe_id = :new.t1_appnt_evnt_id
for update;    

Теперь сессия 2 триггер должен ожидать сессии 1, чтобы фиксировать или откатывать, прежде чем это выполнит проверку.

Это было бы намного более простым и более безопасным реализовать индекс Dave Costa!

Наконец, я рад, что никто не предложил добавить ПРАГМУ AUTONOMOUS_TRANSACTION к Вашему триггеру: это часто предлагается на форумах и работах в так, как видоизменяющаяся проблема таблицы уходит - но она делает проблему целостности данных еще хуже! Поэтому просто не делайте...