т.е. если перед обновлением выдать команду
ALTER DATABASE BEGIN BACKUP
после чего всё начинает писаться в дельту
далее сделать обновление и если всё удачно выполнить
ALTER DATABASE END BACKUP
а если нет то что?
как отказаться от слияния с delta?

kdv,

если так делать то как потом разблокировать?
например сделал ALTER DATABASE BEGIN BACKUP
сделал изменения в данных
вырубил firebird
убрал в сторону delta файл
теперь при попытке соединиться вываливает
iSQLStatement failed, SQLSTATE = 08001
I/O error during "CreateFile (open)" operation for file "D:\MIKSRC\DB\APTM.FDB.delta"
-Error while trying to open file
-Das System kann die angegebene Datei nicht finden.

попробовать подсунуть delta нулевого размера (пустую)?

тогда получаем:
iSQLStatement failed, SQLSTATE = 08001
I/O error during "ReadFile" operation for file "D:\MIKSRC\DB\APTM.FDB.delta"
-Error while trying to read from file
-Ende der Datei (EOF) erreicht.
-internal Firebird consistency check (Can't actualize alloc table)

получается надо слепить delta файл без изменений и его подсовывать

тут правда встаёт вопрос годится ли эта дельта для всех случаев позднее или нет.
Можно конечно сначала делать дельту пустую, потом вырубать сервер её откладывать в сторону потом опять пускать сервер, сливать с ней, опять переводить в backup режим, делать обновление и если надо опять выключать но подсовывать первую delta в которой нет изменений. Шас попробую

такой трюк помогает с базой соединиться
но при попытке выдать команду:
ALTER DATABASE END BACKUP
получаем:
This operation is not defined for system tables.
unsuccessful metadata update.
ALTER DATABASE failed.
Database is not in the physical backup mode.
------------------------------------------------
SQLCODE: -607
SQLSTATE: 42000
GDSCODE: 335544351

Останавливаем FB опять, подсовываем обратно вторую дельту (с изменениами) и
ALTER DATABASE END BACKUP
проходит без проблем

означало ли это сообщение что можно теперь эту (первую, без изменений) дельту просто выкинут и работать дальше? Почему тогда в последствии при подсовывании последней delta (с изменениями) команда ALTER DATABASE END BACKUP прошла нормально?
если выдать команду ALTER DATABASE END BACKUP когда база не находится в Backup режиме сообщение получаем точно такое же.

Получается надо почитать документацию по nbackup. И после этого немного подумать мозгом на
тему "чем твои телодвижения отличаются от "сделать бэкап перед операцией, восстановить его
при неудаче"".

это понятно, просто хотелось разобраться в принципе возможно такое или нет используя delta файл.
Сейчас попробовал все варианты, получается пока не подсунешь правильную (последнюю) delta ничего не получается. Где то в системных таблицах сохраняется или ID этой delta или что то подобное. Можно конечно копать в сторону подмены этого ID в системных таблицах, не факт правда что это получится и туда есть доступ.
По идее тут должно помочь решение когда delta утеряна, испорчена итп.
Есть такое?

короче можно так:
1. Переводим базу в режим резервного копирования (все изменения идут в delta файл) командой ALTER DATABASE BEGIN BACKUP
2. Делаем обновление итп всё что нужно
3. Если всё хорошо выходим из режима резервного копирования и сливаем дельту с базой командой ALTER DATABASE END BACKUP
4. Если по каким либо причинам надо откатить изменения
5. Останавливаем FB
6. Переносим delta файл в безопасное место (на всякий случай)
7. Запускаем FB
7. Запускаем nbackup.exe -F <база данных> это удалит ссылку на дельту в базе и разблокирует её.
Далее всё в обычном режиме, сейчас проверил, работает как задумано.
Побочных эффектов не замечено.
Было бы интересно узнать что конкретно делает nbackup с ключём -F и можно ли это сделать без nbackup напрямую запросами в FB.

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

согласен, конечно сначала всех отсоединить, но это как бы понятно думаю было.
Кстати эксперементировал с FB 3
надо будет ещё с 2.5 проверить.

Только не говори, что в документации к nbackup это не написано...

да, есть, но как менять эти флаги запросами непонятно. В доке по FB они даже не упоминаются (по крайней мере я пока не нашел):
nbackupWithin the file, the state flag is changed from locked (nbak_state_stalled) to normal
(nbak_state_normal);

опять же nbackup -F работает на файловом уровне а не через сервер.

я же писал вверху что если просто удалить delta то потом с базой нельзя соединиться, и ошибку привёл. А чтобы выполнить ... end backup надо по меньшей мере сначала соединиться с базой. Для этого перевести её в normal режим. Или я что то недопонимаю? ALTER DATABASE END BACKUP снаружи ведь выполнить нельзя, даже параметра "файл базы данных" нет.

Dimitry Sibiryakov,

согласен, читаю сейчас.

Поправка - запускать FB перед запуском nbackup -F ненужно, он работает с файлом базы напрямую.

Прочитал, кстати, спасибо kdv за перевод.

Информации по изменению флага средствами FB так и не нашел. То что nbackup правит его на
файловом уровне, без участия FB ведь не значит что сам FB не может менять его тоже. Поэтому этот вопрос пока остаётся открытым.

Небольшое дополнение ко всей этой истории.
Дело в то что размер базы данных бывает очень большим, у некоторых клиентов исчисляется терабайтами. Люди которым приходится делать обновление у клиентов вынуждены работать по ночам и выходным (дабы не останавливать фирмы на время обновления). Резервная копия (инкрементная) к моменту начала обновления всегда уже существует, но что бы её накатить нужны часы, иногда ночи недостаточно. Поэтому давно витала идея как то эту проблему обойти. Если работать через дельту то откат можно произвести в течении минут, при этом на крайний случай конечно иметь резервную копию. Со спеца снимается временное давление и он сможет спокойно решить проблему и накатить обновление снова. Более того успеть обслужить нескольких клиентов.
Поэтому спасибо всем за советы и за критику. Хотелось бы ещё услышать аргументы против такого решения, где это может споткнуться. Например возможна ли ситуация при работе с дельтой когда что то может пойти не так как предполагается (с точки зрения обновления метаданных итп). То что нормальная резервная копия есть это как бы подразумевается.

Спасибо