Каталог решений - Восстановление работоспособности базы 1С 8.1 (файловой)

База «падает» с ошибкой dbeng8, виснет? Еще не все потеряно! Есть 8  методов, которыми можно попытаться «поднять» упавшую файловую базу 1С 8.1. Но вначале нужно сделать резервную копию — простым копированием папки базы, выгрузка не всегда может быть корректна.

Теперь можно начинать процедуру восстановления. Что можно сделать?

1) Удалить все файлы в папке базы, кроме самого файла базы. При новом запуске служебная информация пересоздастся и будет правильной.
2) Запустить chdbfl. Утилиту, которая лежит в bin, рядом с запускаемым файлом 1С. Она протестирует физическую целостность таблиц базы.
3) Исправить метаданные конфигурации (начиная с 8.1.10) Вызывается из конфигуратора, конфигурация/проверка конфигурации, нужны две верхних галочки
4) Вызвать из конфигуратора тестирование-исправление базы. Флажки установлены по-умолчанию, для тестирования этого, обычно, достаточно.
5) Выгрузить базу в файл *.dt и потом загрузить его вновь.
6) И, если ничего не помогает, попробовать сменить версию платформы на более свежую и повторить указанные действия уже на ней. Впрочем, это может быть и первым шагом.
7) Если база открывается, но  не работает, можно попытаться спасти данные, выгрузив их с помощью выгрузки или обмена в идентичную пустую базу.
8) Все вышеуказанное не помогает? Тогда остается последний шанс. Можно переслать базу в 1С (адрес есть в партнерской конференции, но нужно договориться).

Ну а чтоб падения не были такими смертельными — ставьте везде одну и ту же версию платформы, никогда не храните базы на FAT… и сделайте, наконец, автоматическое резервное копирование!

P.S. Спасибо coder1cv8, напомнил еще одну возможность для восстановления. При динамическом обновлении конфигурации в базе иногда возникает рассогласование конфигурации на разных компьютерах — последние версии 1С хранят копии конфигураций локально, в кэше. Если при сетевом доступе на одной машине база работает, а на другой нет, — нужно на неработающем компьютере удалить запись о базе в начальном диалоге и создать ее заново, при этом кэш будет пересоздан.

P.P.S. Еще один найденный «в боевых условиях» метод. Признаки ошибки — после сбоя в какую-то таблицу базы попала запись с NULLевыми значениями. Тестирование-исправление при этом падает на реструктуризации, отобрать и удалить пустую запись не получается просто так — ни отборы запросом, ни «кодовые» методы ее не видят. Найденное решение  — смотрим в «операциях» ошибочную таблицу отсортированную по возрастанию, считаем количество ошибочных записей. Потом получаем всю таблицу запросом с сортировкой по возрастанию и записываем обратно уже без n-первых ошибочных записей.