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

Чаще всего слетает генератор у таблицы, которая отвечает за журналирование изменений в БД.
Запись в таблицу только из одной хранимой процедуры, которая вызывается из тригеров на вставку/обновление/удаление для 50 разных таблиц.
Из программного кода эта таблица только читается - никаких изменений в эту таблицу не проводится.

Несколько раз такое возникло и в других таблицах (генераторы тоже "отставали"), где запись происходит из клиентского интерфейса. Отношение возникновения ситуаций в дургих таблицах к протоколу, где-то 1к50. Но это по причине того, что в протоколе фиксируется значительно больше строк.

Везде генераторы работают по "классике" - в BEFORE INSERT. Т.е. теоретически значение генератора должно инкрементироваться еще до того, как этот идентификатор "ляжет" в таблицу.

Вопрос Гуру - может ли произойти запись в таблицу без записи изменений в таблице генераторов, если генератор инкрементится в тригере?

БД в одном фале - может ли как-то влиять структура файловой системы? У нас виртуальный сервер?

Может есть какие-то настройки кеша (буфера), которые можно "подергать"?

UPD: еще вопрос. Может ли влиять как-то SWEEP=0 ? У меня "свип" по расписанию каждые 3 часа вызывается, а в самой БД интервал сброшен.

Dimitry Sibiryakov, про виртуальный сервер я ошибочно знак вопроса поставил.
Расширение FDB


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

Решил посмотреть в лог-файл сервера.

Очень много записей с ошибкой формата:
Clump N at offset NNNNNN

А потом вот такая:
Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long

Быстрый гуглинг не привел к результату - не может ли это быть следом из одной и той же проблемы?

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

Когда ТС проигнорировал все вменяемые советы - не остаётся ничего другого.


Какие вменяемые советы были проигнорированы? Поставить "ELSE", чтобы "поймать", что кто-то пишет свой айди?
Нет, т.к. данная таблица не пользовательская и пользовательский код в нее не пишет нигде. Все делается в тригерах БД.
Еще раз повторю - это протокол изменений БД
Т.е. там фиксируется информация, в какой таблице БД, в какое время, какая запись была добавлена/изменена/удалена
Запись в эту таблицу с клиента не предусмотрена кодом.
Файл БД не расшарен (у нас с этим все очень строго).
Расширение файла (не знаю, на что оно влияет) я вам написал.


В ходе спора про проверку на нул, могли не заметить мой вопрос про протокол сервера.

Посмотрите на него пожалуйста - я через гугл пока не нашел внятного объяснения появления этой ошибки кроме вот этого: http://www.firebirdfaq.org/faq320/

Но там лишь рекоменадция все на UTF8 перевести, а у меня все работает в 1251

Dimitry Sibiryakov,
мог ошибиться в версии FB - где посмотреть реальный № версии?

2.1.1.17910

Как это возможно и где это можно искать?