Как восстановить конфигурацию 1С после аварийного завершения обновления и исправить «Ошибку формата потока»

← На главную

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

В этой статье мы подробно разберем, почему возникает эта проблема, что происходит с таблицами базы данных в этот момент, и рассмотрим несколько эффективных способов реанимации системы как для клиент-серверного (SQL), так и для файлового вариантов работы.

Почему возникает «Ошибка формата потока» при прерванном обновлении?

Для того чтобы понять логику восстановления, проанализируем внутреннее устройство хранения конфигурации в СУБД. В любой базе данных 1С (будь то MS SQL, PostgreSQL или файловый вариант .1CD) метаданные хранятся в виде бинарных данных в специальных системных таблицах. Наиболее важными для нас являются:

Config — здесь хранится основная конфигурация базы данных, с которой работают пользователи в режиме предприятия.
ConfigSave — в этой таблице находятся изменения, которые мы вносим в Конфигураторе, но еще не применили к базе данных (не нажали клавишу F7).
DBSchema — структура таблиц базы данных под текущие метаданные.

Когда мы запускаем процесс обновления (динамическое обновление или принятие изменений), платформа 1С создает в таблице Config служебную запись. В поле имени файла (которое в SQL-таблице называется FileName) записывается маркер «commit». Наличие этой записи сигнализирует платформе о том, что транзакция обновления находится в процессе выполнения. Если в этот момент сервер или компьютер разработчика экстренно выключается, маркер «commit» остается заблокированным в таблице в поврежденном или незавершенном состоянии. При следующем запуске платформа видит этот флаг незавершенной транзакции и блокирует доступ к конфигурации, выдавая ошибку формата потока.

---

Способ 1. Восстановление конфигурации на уровне СУБД (MS SQL / PostgreSQL)

Если ваша база данных работает под управлением Microsoft SQL Server или PostgreSQL, это самый надежный и быстрый способ исправления ситуации. Нам потребуется удалить ту самую зависшую запись транзакции напрямую через консоль СУБД.

Важно: Перед выполнением любых операций с таблицами базы данных на уровне SQL в обязательном порядке сделайте резервную копию базы средствами СУБД (создайте .bak-файл или дамп PostgreSQL)!

Разберем по шагам процесс очистки таблиц для MS SQL Server:

Запустите среду SQL Server Management Studio (SSMS) и подключитесь к вашему серверу баз данных.
В дереве объектов выберите поврежденную базу данных и нажмите кнопку «Создать запрос» (New Query).
Для начала проверим наличие зависшего маркера транзакции. Напишем и выполним следующий запрос:


SELECT * 
FROM dbo.Config 
WHERE FileName = 'commit';

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


DELETE 
FROM dbo.Config 
WHERE FileName = 'commit';

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

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

TRUNCATE TABLE dbo.ConfigSave;

После очистки таблицы ConfigSave конфигурация вернется к своему исходному («чистому») состоянию до начала злополучного обновления, и вы сможете заново начать процесс модификации метаданных.

---

Способ 2. Использование ключа командной строки /IBRestoreIntegrity

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

Рассмотрим, как запустить этот процесс:

Откройте командную строку Windows (cmd) от имени администратора.
Введите команду запуска конфигуратора с флагом восстановления целостности информационной базы. Шаблон команды выглядит следующим образом:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "ПутьКБазеДанных" /N "ИмяАдминистратора" /P "Пароль" /IBRestoreIntegrity

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


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /N "ИмяАдминистратора" /P "Пароль" /IBRestoreIntegrity

При запуске с ключом /IBRestoreIntegrity платформа в фоновом режиме анализирует структуру базы данных на наличие оборванных сессий реструктуризации, автоматически удаляет поврежденные служебные записи (включая пресловутый «commit») и восстанавливает согласованность конфигурации базы данных.

---

Способ 3. Пересадка конфигурации из архивной копии через SQL

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

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

Разверните на вашем SQL-сервере архивную (здоровую) копию базы данных под именем, например, Test_Base_Copy.
Убедитесь, что никто не работает с поврежденной рабочей базой данных (допустим, она называется Work_Base_Broken).
Выполните SQL-запрос для полной очистки поврежденной таблицы конфигурации в рабочей базе:

DELETE FROM [Work_Base_Broken].[dbo].[Config];

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


INSERT INTO [Work_Base_Broken].[dbo].[Config] 
SELECT * FROM [Test_Base_Copy].[dbo].[Config];

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

---

Способ 4. Реанимация файлового варианта базы данных (.1CD)

Что делать, если база данных файловая, и у нас нет прямого доступа к SQL-серверу для выполнения запросов? Для файловых баз существуют свои эффективные инструменты.

Использование утилиты Tool_1CD

Утилита Tool_1CD — это известная в сообществе разработчиков программа для прямого чтения и редактирования файлов баз данных 1С формата .1CD без использования самой платформы. С её помощью мы можем провести те же манипуляции, что и в SQL:

Сделайте резервную копию файла 1Cv8.1CD.
Откройте этот файл в утилите Tool_1CD.
Найдите таблицу Config в списке таблиц базы данных.
Перейдите во вкладку просмотра записей таблицы, найдите строку, у которой в колонке FileName записано значение «commit», и удалите эту строку.
Сохраните изменения и закройте утилиту. После этого запустите базу в режиме Конфигуратора 1С.

Стандартная утилита chdbfl.exe

Не пренебрегайте стандартным инструментом проверки физической целостности файлов баз данных. Утилита chdbfl.exe находится в каталоге установленной платформы (в папке bin вашей версии платформы, например: C:\Program Files\1cv8\8.3.23.1688\bin\chdbfl.exe).

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

---

Способ 5. Очистка кэша конфигурации (первое действие перед началом ремонта)

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

Откройте список баз данных в окне запуска 1С.
Выберите поврежденную базу, нажмите кнопку «Удалить», а затем добавьте её заново с тем же путем или адресом сервера. При этом старый кэш отвяжется, а для базы создадутся новые чистые папки временных файлов.
Для полной уверенности вручную удалите папки кэша. Закройте все приложения 1С и очистите содержимое каталогов:

%USERPROFILE%\AppData\Local\1C\1cv8
%USERPROFILE%\AppData\Roaming\1C\1cv8

После удаления этих директорий запустите систему. Если ошибка была вызвана локальным кэшем, база откроется без каких-либо дополнительных манипуляций.

Проанализировав все представленные методы, мы видим, что даже при полном отсутствии актуального бэкапа базы данных, восстановить работоспособность 1С после сбоя при обновлении вполне возможно. Главное — четко понимать структуру хранения метаданных и последовательно применять инструменты СУБД или утилиты восстановления файлов.