Ситуация, когда в процессе обновления конфигурации 1С происходит программный сбой или отключение питания, является критической для системного администратора и программиста. Часто это приводит к тому, что информационная база продолжает работать в режиме «Предприятие», но при попытке зайти в Конфигуратор система выдает «Ошибку формата потока» или сообщает о незавершенной операции сохранения. В этой статье мы подробно разберем, как восстановить работоспособность базы данных, используя инструменты SQL Server Management Studio (SSMS).
При обновлении конфигурации 1С:Предприятие выполняет несколько последовательных этапов записи данных в SQL-таблицы. Основные данные хранятся в таблице Config (актуальная конфигурация базы данных) и ConfigSave (сохраняемая основная конфигурация). Если сбой произошел в момент фиксации изменений, в этих таблицах могут остаться служебные записи-флаги, такие как commit или dbStruFinal, которые блокируют запуск Конфигуратора, так как система считает предыдущую сессию редактирования незавершенной.
Прежде чем выполнять любые манипуляции с таблицами базы данных на уровне SQL, необходимо создать полную резервную копию (Full Backup) текущего состояния базы. Даже если база повреждена, наличие актуального слепка данных позволит нам вернуться к исходной точке в случае неудачных правок. Рассмотрим ситуацию, когда у нас есть «здоровая» копия базы (например, недельной давности), из которой мы будем брать эталонные структуры конфигурации.
Первым делом попробуем устранить программные «флаги», которые сигнализируют системе о незавершенном обновлении. Откроем SQL Server Management Studio и выполним следующий запрос к проблемной базе данных:
DELETE FROM dbo.Config WHERE FileName = 'commit';
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal';
Разберем, что делают эти команды. Запись commit указывает системе на начало транзакции обновления конфигурации. Если она остается в таблице после падения процесса, Конфигуратор не может инициализировать структуру метаданных. Запись dbStruFinal отвечает за финальный этап реструктуризации таблиц. Удаление этих строк часто помогает «обмануть» систему и разрешить вход в Конфигуратор.
Если очистка служебных записей не помогла и ошибка формата потока сохраняется, значит повреждена сама основная конфигурация в таблице ConfigSave. В этом случае нам поможет перенос данных из архивной (исправной) базы. Предположим, что Work_Base — это наша сломанная база, а Archive_Base — база из бэкапа.
Проанализируем и выполним следующую последовательность действий:
ConfigSave в рабочей базе.
-- Очищаем таблицу в целевой базе
DELETE FROM Work_Base.dbo.ConfigSave;
-- Переносим данные из архивной базы
INSERT INTO Work_Base.dbo.ConfigSave
SELECT * FROM Archive_Base.dbo.ConfigSave;
После выполнения этого запроса попробуйте запустить Конфигуратор. В большинстве случаев это позволяет зайти в режим разработки, так как структура основной конфигурации теперь соответствует «здоровому» состоянию из бэкапа.
Иногда проблема кроется глубже — в таблице DBSchema, которая хранит описание физической структуры таблиц SQL. Если обновление прервалось на этапе реструктуризации, данные в DBSchema могут не соответствовать реальному составу колонок в таблицах данных. В такой ситуации выполнение «Тестирования и исправления» может быть недоступно.
Рассмотрим метод восстановления через замену DBSchema. По аналогии с предыдущим шагом, мы можем попробовать скопировать эту таблицу из бэкапа, но только в том случае, если версия метаданных в бэкапе совпадает с той, которая была до начала неудачного обновления. Если структура таблиц уже успела измениться, этот метод может привести к потере данных, поэтому действуйте крайне осторожно.
Если после всех манипуляций в SQL Конфигуратор все равно выдает ошибку, необходимо исключить влияние кэша сервера 1С:Предприятие. Посмотрим, как правильно выполнить полную очистку:
srvinfo (обычно в C:\Program Files\1cv8\srvinfo).snccntx. Там хранятся сеансовые данные, которые могут содержать «битый» образ конфигурации.В некоторых случаях графический интерфейс 1cv8.exe не может обработать поврежденный поток, но движок платформы способен завершить обновление через командную строку. Попробуем инициировать принудительное обновление конфигурации базы данных:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ServerName\BaseName" /UpdateDBCfg
Параметр /UpdateDBCfg заставляет платформу попытаться синхронизировать Config и ConfigSave. Если транзакция реструктуризации была «заморожена», этот метод может ее протолкнуть.
Восстановление после падения обновления на SQL требует комплексного подхода. Мы начали с удаления флагов commit, перешли к восстановлению таблиц ConfigSave из архива и закончили очисткой серверного кэша. Помните, что после успешного входа в Конфигуратор обязательно следует выполнить операцию «Конфигурация — Проверить конфигурацию» и запустить полное «Тестирование и исправление» с проверкой логической и ссылочной целостности, чтобы убедиться, что сбой не оставил «хвостов» в данных пользователей.