В базе есть таблица с сальдо-оборотами абонентов. В ней есть триггер, который обновляет начальное сальдо следующего периода при изменении конечного сальдо (AFTER UPDATE):


В FB 2.5 все работало. В FB 3.0 же при выполнении вот такой команды начальное сальдо следующего периода не обновляется:


Если во втором условии сделать "=", то все работает - сальдо переносится.
Сделал лог изменения начального сальдо по одной услуге. Получилась вот такая картина (201804, 201805 - это значения ID_PERIOD):
1 201804: 143.85 -> 143.85
2 201805: 231.55 -> 431.55
3 201805: 431.55 -> 231.55
Если я правильно понимаю, то получается следующая последовательность:
1. В записи 201804 обновляется конечное сальдо.
2. Это вызывает обновление начального сальдо у записи 201805.
3. После этого сервер переходит к записи 201805, обновляет ее, "вспоминая", что на момент старта запроса у него было другое начальное сальдо. И тем самым возвращает все как было.

Вопросы: такое поведение так и задумывалось? если да, то как тогда делать каскадные обновления записей, когда следующее обновление записи зависит от другого?

Симонов Денис,

Оно работало во всех версиях FB по вполне логичной причине - запись обновили, и сервер при обработке следующей записи видит измененную версию.
И все таки, как сделать каскадное обновление - есть варианты?

Тогда уважаемые hvlad и kdv, объясните, как правильно реализовать следующее:
NROW STARTAMOUNTFINISH1000200030554505
Поле FINISH = START + AMOUNT.
Требуется, чтобы при изменении поля FINISH у любой строки, обновлялось поле START у последующих строк. Например, вот так:NROW STARTAMOUNTFINISH1044240434594909
Сейчас это сделано простым способом - в триггере AFTER UPDATE, если меняется поле FINISH, обновляется поле START у следующей строки, и так каскадом обновляется весь стек. В обычных случаях каскад состоит из одной-двух строк, поэтому никаких проблем с производительностью и прочим нет. Ничего криминального тут не вижу. Плюс это очень удобно, так как при обновлении поля AMOUNT автоматом обновляются последующие строки - никаких дополнительных запросов выполнять не требуется.

Другие варианты:
1. Обновление через еще один апдейт.


Не проверял, но на 99% уверен, что это так же работать это не будет.
2. Обновление через ХП, которая будет пересчитывать поле START, начиная со следующей строки:


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

hvladпри изменении AMOUNT прибавь дельту к AMOUNT и FINISH в текущей записи и прибавь ту же дельту к START и FINISH всем последующим записям.
Для этого нужен один UPDATE, показать ?
Мысль понял, попробую через дельту.

hvladИли ты меняешь AMOUNT массово, более чем одной записи за раз ?
Да. Проблема в том, что в примере NROW - 1 колонка. А в реальности уникальный код строки состоит из трех колонок. Для большей ясности могу сказать, какие - это код абонента, которых 200 тысяч, код услуги (например, горячая вода, отопление, электричество) и месяц (январь 2018, февраль 2018 и т.д.). В большинстве случаев изменение делается по условию двух из них - абонент и месяц - то есть одним апдейтом обновляется AMOUNT у нескольких услуг.

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