Ошибка при каскадном удалении

[Heimdallr]

Имеют место быть:

firebird 1.5 CS

/* Одна таблица: */
CREATE TABLE MASTER (
ID_DOC INTEGER NOT NULL,
/* Ещё всякие поля */
);
ALTER TABLE MASTER ADD CONSTRAINT PK_MASTER PRIMARY KEY (ID_DOC);

/* Еще таблица: */
CREATE TABLE DETAIL (
ID INTEGER NOT NULL,
ID_DOC INTEGER NOT NULL,
/* Ещё всякие поля */
);
ALTER TABLE DETAIL ADD CONSTRAINT PK_DETAIL PRIMARY KEY (ID);
ALTER TABLE DETAIL ADD CONSTRAINT FK_DETAIL FOREIGN KEY (ID_DOC) REFERENCES MASTER (ID_DOC) ON DELETE CASCADE ON UPDATE CASCADE;

Проблема:
Пытаюсь удалить строку из MASTER, получаю

violation of FOREIGN KEY constraint "".
violation of FOREIGN KEY constraint "FK_DETAIL" on table "DETAIL".

Дополнительные сведения:
Поблема возникает на одной из двух (идентичных по метаданным) базах, backup/restore не помогает.

И, наконец, вопрос:
Куда копать кроме как в сторону замены внешнего ключа триггером before delete?

[kdv]

копать в сторону своих триггеров или процедур, навешаных на этих таблицах. Наверняка там висит нечто, что мешает сработать каскадному удалению.
Удалить этот FK, посмотреть, не осталась ли связь между этими таблицами, явная или косвенная (попробовать удалить запись из мастера и посмотреть что будет - ошибка, удалятся детали или не удалятся).

Кстати, каскадное обновление - зло. Первичные ключи обычно никто никогда не модифицирует. on delete еще туда-сюда...

[Merlin]

Проверить наличие делетных триггеров на обеих таблицах и посмотреть на их код под углом того факта, что при каскаде происходит временное нарушение RI - сначала удаляется мастер, а потом детали.

[Heimdallr]

Спасибо ответившим.
Убил вышеупомянутый foreign key, создал его заново без каскадного обновления (ибо действительно "зло"). Все заработало, но причины косяка остались неясными. На обеих таблицах висят триггеры после удаления, но там только post_event 'table_типа_changed_ага', к тому же на другой базе (с аналогичной структурой) все работает... Так что тема продолжает интересовать, но уже чисто академически.

[Merlin]

Скорее всего была смесь DDL и DML в одной транзакции или какая-нить чехарда с кешем метаданных при DML в транзакции, начатой до выполнения или коммита DDL. На что провоцируют многооконные инструменты. Реально изменения метаданных выполняются только на коммите, а во время выполнения оператора всего лишь пишутся данные в системные таблицы для этого.