← На главную

В процессе эксплуатации файловых баз 1С (файл 1Cv8.1CD) нередко происходят сбои, вызванные внезапным отключением питания, аварийным завершением работы пользователей или зависанием платформы во время динамического обновления. Одной из самых неприятных ситуаций является ошибка вида «Таблица не найдена: _ReferenceXX» (или аналогичное системное имя таблицы документа, регистра сведений и т. д.). При этом стандартное тестирование и исправление падает с критической ошибкой, а утилита chdbfl.exe сообщает, что ошибок не обнаружено.

Разберем природу этого поведения платформы, проанализируем, почему стандартные подходы не дают результата, и рассмотрим эффективный способ восстановления структуры базы данных.

Почему штатные механизмы не решают проблему

Выясним причину, по которой привычные методы администрирования оказываются бессильны:

1. Поведение утилиты chdbfl: штатная программа проверки файла базы данных анализирует физическую целостность страниц, цепочек блоков и B-деревьев. Если дескриптор таблицы в заголовке поврежден или был исключен самой же утилитой при предыдущей жесткой проверке, файл считается физически консистентным. Утилита chdbfl.exe не сопоставляет внутренние таблицы со схемой метаданных конфигурации 1С.
2. Ограничения механизма загрузки конфигурации (файла .cf): при попытке загрузить конфигурацию из рабочего бэкапа того же релиза платформа сравнивает конфигурацию файла с конфигурацией базы данных. Если состав метаданных идентичен, платформа не инициирует процедуру реструктуризации на физическом уровне, и отсутствующая таблица просто не создается заново.
3. Блокировка реструктуризации при попытке изменить метаданные: если мы попытаемся принудительно изменить объект (например, добавить фиктивный реквизит в справочник), платформа перед изменением структуры физической таблицы попытается прочитать ее существующее состояние. Столкнувшись с физическим отсутствием контейнера _ReferenceXX, процесс мгновенно завершится аварийно.

Способ 1. Восстановление таблицы через специализированную утилиту Tool_1CD

Если база данных работает в клиент-серверном варианте (MS SQL Server, PostgreSQL), администратор может просто перенести таблицу со схемой из резервной копии штатными средствами СУБД. В файловом варианте такой возможности «из коробки» нет, поэтому воспользуемся версией утилиты Tool_1CD с поддержкой редактирования структуры базы.

Пошагово разберем порядок действий:

1. Создание полной резервной копии: обязательно сохраняем копию поврежденного файла 1Cv8.1CD перед любыми низкоуровневыми манипуляциями.
2. Подготовка структуры из исправной базы: берем имеющийся бэкап или создаем новую пустую базу из рабочей конфигурации (того же релиза). Открываем файл исправной базы в утилите.
3. Экспорт описания таблицы: находим в списке таблиц ту, на которую ругается система (в нашем случае системное имя соответствовало справочнику банковских счетов, например _Reference19). Экспортируем структуру и метаданные пустой таблицы в промежуточный файл.
4. Импорт таблицы в поврежденную базу: открываем в утилите битый файл базы и выполняем операцию внедрения/создания недостающей таблицы с идентичной сигнатурой полей и индексов.
5. Проверка платформой: сохраняем изменения и запускаем базу в режиме «Конфигуратор». Теперь физический контейнер присутствует в файле, и платформа может обращаться к объекту без фатального сбоя.

Способ 2. Конвертация формата страниц при несовместимости версий

Современные версии платформы 8.3 могут использовать файловые базы с размером страницы 8, 16, 32 или 64 Кб, тогда как некоторые версии низкоуровневых редакторов работают исключительно с классическим форматом 4 Кб. Рассмотрим, как обойти это ограничение:

1. В каталоге установки платформы (папка bin) находим консольную утилиту cnvdbfl.exe.
2. Конвертируем поврежденную базу к базовому размеру страниц 4096 байт с помощью командной строки.
3. Выполняем внедрение таблицы через низкоуровневую утилиту, как описано в первом способе.
4. При необходимости возвращаем исходный размер страницы с помощью той же cnvdbfl.exe.

Завершающие действия после восстановления структуры

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

1. Тестирование и исправление: запускаем Конфигуратор и открываем меню Администрирование -> Тестирование и исправление.... Включаем проверки логической и ссылочной целостности, а также реиндексацию таблиц. Поскольку внедренная таблица была пустой, система очистит или пометит как «Объект не найден» битые ссылки в связанных документах и регистрах.
2. Восстановление утерянных данных: переносим актуальные данные поврежденного справочника из резервной копии с помощью типовой обработки «Универсальный обмен данными в формате XML» или механизмов прямой синхронизации данных.