Как восстановить таблицу CONFIG в файловой базе 1С после неудачного динамического обновления?

Динамическое обновление конфигурации в 1С (в народе часто именуемое «демоническим») — удобный, но весьма рискованный инструмент. В файловых информационных базах формата 1Cv8.1CD любой сбой в момент сохранения или реструктуризации на лету часто приводит к полной блокировке входа как в пользовательском режиме («1С:Предприятие»), так и в режиме «Конфигуратор». Разберем подробно, почему это происходит и как восстановить работоспособность базы, используя резервную копию и специализированные инструменты.

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

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

1. В служебных таблицах CONFIG и CONFIGSAVE создаются специальные маркеры состояния и временные объекты с именами вроде commit, dbStruFinal, dynamicCommit и DynamicallyUpdated.
2. Платформа готовит транзакцию для подмены версий метаданных на лету.
3. Если во время записи происходит сетевой сбой, аварийное завершение процесса 1cv8.exe или переполнение кэша, база остается в промежуточном «зависшем» состоянии.

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

Первичные шаги: очистка кэша и попытка отката через командную строку

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

1. Создание полной копии каталога базы данных. Скопируем текущий поврежденный файл 1Cv8.1CD в надежное место. Все дальнейшие манипуляции проводим исключительно с копией.
2. Полная очистка локального кэша 1С. Динамическое обновление повреждает кэш конфигурации на клиентских машинах. Очистим каталоги по путям %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8.
3. Попытка отката конфигурации через параметры запуска. Попробуем выполнить принудительную отмену незавершенного обновления через командную строку.

Рассмотрим пример команды для сброса незавершенной транзакции обновления:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "C:\Bases\MyBase" /RollbackCfg

Если откат не помог, можно также попробовать выполнить команду принудительного обновления конфигурации базы данных:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "C:\Bases\MyBase" /UpdateDBCfg -Dynamic-

Если эти шаги не привели к успеху, перейдем к восстановлению таблиц конфигурации из бэкапа.

Восстановление таблицы CONFIG с помощью бэкапа и утилиты Tool_1CD

Проанализируем ключевое условие: динамическое обновление платформы 1С принципиально невозможно, если разработчик вносил изменения в структуру данных (добавлял новые реквизиты, менял типы, создавал новые объекты метаданных). Это означает, что структура таблиц данных в битой базе полностью совпадает со структурой в бэкапе недельной давности. Различаются только сами введенные данные и поврежденная таблица конфигурации.

Следовательно, мы можем взять валидную таблицу CONFIG (а также CONFIGSAVE и PARAMS) из недельной копии и перенести ее в рабочую базу. Для работы с файлами 1Cv8.1CD применим утилиту Tool_1CD.

Разберем по шагам весь процесс переноса:

1. Открываем файл резервной копии 1Cv8.1CD в программе Tool_1CD.
2. Находим в списке таблиц служебные таблицы CONFIG, CONFIGSAVE и PARAMS.
3. Выполняем экспорт данных таблиц в файлы дампов на диск.
4. Открываем в утилите поврежденный файл рабочей базы данных.
5. Выполняем операцию импорта выгруженных таблиц с полной перезаписью существующих.
6. Сохраняем изменения в файле базы данных.

Решение проблемы несовместимости форматов через утилиту cnvdbfl.exe

Многие версии утилит прямого редактирования файлов 1Cv8.1CD корректно работают только с форматами базы 8.2.14 или 8.3.8 и не поддерживают напрямую формат 8.3.14+. В такой ситуации используем штатный конвертер платформы cnvdbfl.exe, расположенный в папке bin установленной платформы.

Посмотрим на алгоритм действий:

1. Конвертируем поврежденную базу и базу-донор в формат совместимости 8.2.14 с помощью команды:
   Скопировать код

   
   cnvdbfl.exe -c -f 8.2.14 "C:\Bases\DamagedBase\1Cv8.1CD"
   cnvdbfl.exe -c -f 8.2.14 "C:\Bases\BackupBase\1Cv8.1CD"
   

2. Запускаем Tool_1CD и успешно производим замену таблиц CONFIG и CONFIGSAVE.
3. Конвертируем восстановленную базу обратно в актуальный формат 8.3.14 (или выше): cnvdbfl.exe -c -f 8.3.14 "C:\Bases\DamagedBase\1Cv8.1CD"

Альтернативный вариант: удаление маркеров блокировки

Если актуального бэкапа нет или конфигурация в нем существенно устарела, можно попробовать очистить таблицу CONFIG от следов незавершенной транзакции.

Рассмотрим структуру таблицы CONFIG. В ней содержатся записи с именами файлов конфигурации. При аварии в таблице остаются строки commit и dbStruFinal. Если открыть таблицу в режиме редактирования через специализированные сборки утилит и пометить на удаление (или физически удалить) данные строки, платформа при следующем запуске пропустит проверку незавершенного динамического обновления и откроет базу в штатном режиме.

Финальные действия после восстановления

После того как замена таблицы произведена и Конфигуратор успешно запустился, обязательно выполняем регламентные процедуры проверки:

1. Открываем базу в режиме Конфигуратор монопольно.
2. Вносим минимальное фиктивное изменение (например, добавляем пробел в комментарий любого общего модуля) и выполняем полное сохранение конфигурации через меню Конфигурация — Обновить конфигурацию базы данных (горячая клавиша F7). Это заставит платформу заново пересчитать внутренние контрольные суммы и корректно пересобрать кэш метаданных.
3. Запускаем процедуру Администрирование — Тестирование и исправление... со следующими обязательными флагами:
   • Реиндексация таблиц информационной базы
   • Проверка логической целостности
   • Пересчет итогов
4. Запускаем базу в режиме «1С:Предприятие» и проверяем корректность работы введенных за последнюю неделю документов.

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