FB 1.5.2: проблема с восстановлением базы

[Merlin]

Я например, так и не решил для себя что лучше: варнинги и восстановимый бакап или ерор и иди кури доку

Не надо максимализьма Нужны все режимы - умолчательный жёсткий, опциональные для вытаскивания из gbk всего что можно вытащить.

[Boris Kuritsin]

select * from rdb$user_privileges UP
where
UP.rdb$object_type=13
and
not exists(select 1 from rdb$roles RL where RL.rdb$role_name=UP.rdb$relation_name)


Тот же запрос в случае подозрения на битые системные индексы:

<...>

Запрос, о котором говорил в прошлый раз, в случае того же подозрения:

<...>

Если всё это шаманство не помогает, то, возможно, дело в повреждении таблицы RDB$SECURITY_CLASSES. Учить её чинить по переписке я не возьмусь. Кстати, owner менять хакерскими методами у объектов в базе не пытался? Такие попытки при неверной последовательности действий ведут к её повреждениям.

Короче, все эти запросы вернули пустой набор данных. Но решение (может быть, некрасивое) найдено - восстанавливать базу без "commit after each table" - не понимаю почему, но это срабатывает и помогает!

Поэтому спасибо всем за обсуждение и подсказки, тему как животрепещущую можно считать закрытой, а как теоретическую - это вам виднее...

[Boris Kuritsin]

Дискуссия развернулась довольно интересно, но зачастую конкретная проблема автора темы решается установкой (или снятием?) флажка "commit after each table" во время рестора.

Сработало!!! Потрясающе! Но почему?!

[dima_mr]

Вчера столкнулся с аналогичной проблемой. При снятом "commit after each table" все работает, иначе вылетает. Сделал тдельную копию базы, содержащую только метаданные. Далее удалял оттуда объекты частями, проверяя восстановление.
Результат. Данную ошибку 100%- но выдают таблицы, в которых есть COMPUTED BY поля, содержащие UDF. Убрал такие поля (сделал обыкновенные с триггером) - все заработало. Сервер - Firebird 1.5.2.4731