Ситуация, когда база данных 1С перестает открываться из-за "Ошибки формата потока", является одной из самых критических для разработчика или администратора. Если стандартные методы, такие как чистка кэша, запуск тестирования и исправления (ТИИ) или перенос в новую базу через бэкап, не помогают, остается единственный путь — обращение напрямую к таблицам системы управления базами данных (СУБД). Рассмотрим подробнее, как устроено хранение конфигурации в SQL и как можно реанимировать разработку.
Прежде чем приступать к восстановлению, проанализируем ситуацию. Зачастую проблема кроется в механизме динамического обновления или в специфических ошибках платформы (например, версии 8.3.12.1440 и 8.3.12.1469 имели зафиксированные проблемы при работе с расширениями). Когда платформа записывает изменения в базу данных, она использует транзакционную модель. Если в момент записи происходит сбой, данные в системных таблицах могут оказаться в противоречивом состоянии. Ошибка формата потока часто означает, что 1С ожидает увидеть структуру данных одного типа, но получает некорректный или незавершенный набор байтов.
Вся логика метаданных 1С (объекты, модули, формы) хранится в специализированных системных таблицах. Разберем основные из них:
Config — основная таблица, в которой хранится текущая конфигурация базы данных.ConfigSave — таблица, куда записываются изменения конфигурации, которые еще не были применены (сохраненная, но не обновленная конфигурация БД).ConfigCAS и ConfigCASSave — аналогичные таблицы для хранения расширений конфигурации.Данные в этих таблицах распределены по строкам. Каждая строка соответствует определенному внутреннему файлу. Поле FileName содержит имя этого файла, а поле BinaryData — само содержимое в бинарном виде.
Как показывает практика и опыт участников обсуждения, наиболее частой причиной блокировки входа в конфигуратор является "зависшая" запись в таблице ConfigSave. Это происходит, когда динамическое обновление завершилось аварийно. Платформа пытается считать изменения из этой таблицы, натыкается на битый поток и выдает ошибку.
Рассмотрим по шагам процесс очистки этой таблицы через SQL Server Management Studio (SSMS):
SELECT * FROM ConfigSave
Если запрос возвращает строки, значит, в базе есть незавершенные изменения. Попробуйте очистить эту таблицу:
DELETE FROM ConfigSave
После выполнения этой команды попробуйте зайти в конфигуратор. В большинстве случаев этого достаточно, чтобы "откатить" конфигурацию к последнему стабильному состоянию, которое было зафиксировано в основной таблице Config.
Если очистка ConfigSave не помогла, и основная конфигурация в таблице Config также повреждена, мы можем попытаться перенести данные в заведомо "здоровую" оболочку. Проанализируем этот метод:
Config будет содержать только стандартные минимальные записи.BinaryData из поврежденной базы в новую.Важный нюанс: конфигурация 1С — это не один файл, а тысячи записей в таблице. Простое копирование одной строки не даст результата. Нужно скопировать все записи, где FileName соответствует структуре конфигурации. Для этого можно использовать SQL-запрос типа INSERT INTO ... SELECT FROM, предварительно очистив целевую таблицу в новой базе.
Существуют инструменты, разработанные сообществом, которые умеют собирать файл .cf напрямую из SQL-таблиц. Проанализируем наиболее популярные варианты:
Эти утилиты полезны тем, что они автоматически обрабатывают сжатие данных. В SQL-таблицах поле BinaryData обычно упаковано алгоритмом zlib. Если вы просто сохраните значение поля в файл, 1С его не прочитает, так как он будет сжат. Утилиты выполняют декомпрессию "на лету".
Если в вашей базе используются расширения, выясним причину сбоя в них. В современных версиях платформы (начиная с 8.3.12) расширения могут стать источником разрушения структуры потока. Если база не открывается, попробуйте временно очистить таблицы расширений:
DELETE FROM ConfigCAS
DELETE FROM ConfigCASSave
Это действие удалит расширения из базы. Если после этого конфигуратор откроется, значит, проблема была именно в одном из расширений. Вы сможете загрузить их заново из имеющихся файлов или хранилища.
Разберем, как избежать подобных ситуаций в будущем. Во-первых, если база используется для разработки, крайне важно использовать Хранилище конфигурации. Как заметил автор темы, наличие хранилища позволяет не беспокоиться о ежедневных бэкапах базы разработки, так как история кода сохранена отдельно. Во-вторых, старайтесь избегать динамического обновления ("обновление демоном") в версиях платформы, имеющих сомнительную репутацию в плане стабильности. Лучше потратить лишние 5 минут на перезагрузку сеансов пользователей, чем несколько часов на восстановление таблицы Config вручную.
Резюмируя: при возникновении ошибки формата потока в SQL-базе первым делом очищаем таблицу ConfigSave. Если это не помогает — извлекаем данные из Config с помощью специальных утилит или переноса в пустую SQL-базу. Всегда помните о сжатии zlib и о том, что конфигурация — это совокупность множества записей в таблице, а не единый объект.