Nikola18 JohnmenИ я думаю, что это "правильней", т.к. в детальной табл. можно удалять только после удаления в основной. Такой порядок более "устойчив" для обеспечения целостности.
Позволю с Вами не согласиться. Вот как раз для большей "устойчивости" в обеспечении целостности удаление PK должно производиться только после удаления всех ссылок на него.

Кроме всего прочего существует ещё один аспект:
я полагаю, что запись, генерирующая каскадные изменения в базе должна иметь возможность анализировать результат этого каскада, а для этого она должна получить управление после обхода всех FKeys. А при действующей у IB и его клана метадологии это получить нельзя, т.к. триггер PK AFTER XXXXXXXX сработает в начале и всё.
Не думаю, что разработчики IB/FB/Yaffil этого не понимали, поэтому надеюсь, что это либо просто глюк, либо недоработка. Но если это сознательный выбор, то очень хочется чтоб этот выбор был расширен до возможности выбирать пользователем принцип каскадных обновлений/удалений.

Удаляем мастера. Системный триггер срабатывает перед реальным удалением мастера. Детали удалены. Параллельно вставляем новую деталь с сылкой на удаляемого мастера. Что получим ? Правильно - деталь без мастера. А если мастера удалим сначала , то новую деталь уже не вставить.

ЗлобастыйЗдорово, Влад!
Привет

ЗлобастыйЗашел развлечься? ;)
Тут всегда весело...
Да уж ;)