Моя большая и по-видимому не разрешимая проблема в следующем:
есть родительская таблица, на которой проводиться логическое удаление, то есть есть поле dateofarchive котрое апдейтиться ненудевым значением, в случае если запись "удалена", у родительской таблицы есть много дочерних, на которых тоже надо обновить поле dateofarchive у соответствующих дочерних записей, ну чтобы ссылочная целостность сохранилась.
проблема в том что у некоторых дочерних таблиц существуют свои тригера на BEFORE UPDATE котррый поддерживают некоторые бизнес-правила, например нельзя удалить (в нашем случае проапдейтить поле dateofarchive), если дочерняя запись последняя. И вот этот самый триггер конфликтует с родительским триггером, который пытается проапдейтить также все дочерние записи. Мы определили два пути чтобы побороть эту проблему
1) Как-то определить когда дочерний триггер вызван UPDATE выражением в родительском и тогда в процедуре триггера разрешать удаление дочерней записи
Вопрос: как определить что дочерний триггер вызван из родительского? параметры в триггеры не передаются :( Enable/disable тригеру делать в нашем случае нельзя

2) если для родительского триггера использовать AFTER UPDATE, то в дочернем можно проверить, что родитель уже удален и тоже разрешить удаление дочернего, но в это случае проблема как сделать откат в случае сбоя?
В литературе нигде не описано, но по-видимому триггеры не разрешают управление транзакциями, и каждый триггерэто отдельная транзакция. Поэтому если сбой произойдет в одном из дочерних триггеров вызванных родительским, то невозможно сделать откат всех изменений и в родительской таблице, и во всех остальных дочерних.

Если у кого-то будут какие-либо идеи, пожалуйста, пишите.