База "падает" с ошибкой 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-первых ошибочных записей.
