SQLWalkerдумал, что before insert подходит только при вставке новой записи.

так и есть, это тебе на будущее сразу запас сделали.

Хотя я бы делал триггер Before update or insert

Симонов ДенисAriochХотя я бы делал триггер Before update or insert

на хрена? Ты хочешь дёргать генератор при update?

если в новое обязательное поле какая-то старая аппликуха впендюрила NULL - то почему нет?

Гаджимурадов Рустаможидать, что апдейт-триггер как-то
может помочь заполнить PK

Поможет, если сделать update X set ID = ID

Только тут "приоритетность" задач обратная.

Сначала заводим триггер, как One True Way выставлять ID.
Изменяем структуру БД к новому правильному виду.

Затем заставляем стандартные триггер отработать старые записи - единообразия для.
Подтягиваем неправильные данные к правильной структуре.

Хотя современный FB не даст изменить структуру: добавление non-null столбюца без default value.
А генераторы и прочие выражения ЕМНИП в default не вставляются.

Гаджимурадов РустамНадо налабать ненужный апдейт-триггер

С чего бы он ненужный?

Это стандартный триггер описанный в FAQ'ах лет уже 20 наверное как.
И ты это знаешь, но передёрнуть просто необходимо было.
Печально.

Гаджимурадов Рустам,

Триггеры - на заполнение поле из генератора. Они стандартны и общеизвестны.
Я просто изменил условие вызова.
Не "налабал" новый триггер, как ты говоришь, а взял стандартный и изменил один флажок.
В этом твоё передергивание.

Насчет PK не помню. Но некоторые поля подобным триггером заполнялись, которые пустыми быть не должны. Вместо того, чтобы копипастить один и тот же код, он был вбит один раз в триггер.
После чего по таблице был пропущен update.

Но можно, конечно, и копипастить. Возможно так архитектурнее, "быдло" в такой тонкости не разбирается.

Гаджимурадов РустамТы в таких случаях вместо update set =date, =a+b
всегда пишешь триггер if null then = date, =a+b и

Ты старательно забываешь про аппликухи. В том числе - старых версий.

В моем случае - пишется один более-менее сложный триггер. И один холостой update.
Они оба вставляются в апдейтер, после добавления столбца.
Аппликухи можно вообще не трогать, если сервер сам может посчитать данные.

В твоём случае - триггер не пишется, а вместо него пишутся
1) сложный update с вычислением для апдейтера
2,3,4,...) такие же формулы в КАЖДУЮ аппликуху. Даже в те, которым эти данные не нужны. И если где-то аппликуху не обновили (бардак, но в жизни всякое бывает), от в базу лезут незаполненные столбцы

Конечно же, вторая архитектура красивее.
"Don't repeat yourself" быдло придумало.
А архитектор скопирует свой мудрый update в 10 аппликух - и за каждую отдельно оплату получит.
А за будущего мантейнера у него голова не болит, "такой задачи не поставлено".

Гаджимурадов РустамКак/зачем они вообще должны знать про новые поля?

затем, чтобы изменяя другие столбцы этой таблицы, уметь пересчитать новый столбец.


но по твоему, аппликухам не нужно знать про новые поля, если они их не читают.
и я с этим согласен.

поэтому в моем, плохом, варианте - это сделает "ненужный" триггер.
в твоем - хорошем - этого не сделает сама аппликуха, и вообще не сделает никто.

и останутся в том столбце старые данные, необновлённые.
зато архитектура красивая. быдлу не понять.

Потому что извлечь данные из БД - задача отдельная от хранения данных, ага.

Ivan_Pisarevskyтриггер на апдейт меняющий молчком ПК

не меняющий, а заполняющий отсутствующий ПК