Сегодня мы подробно разберем одну из самых неприятных и частых проблем при работе с платформами 1С:Предприятие — «Ошибка формата потока». Проанализируем типичную ситуацию, когда при запуске информационной базы или попытке её обновления система отказывается работать. Мы выясним настоящие причины такого поведения, а также посмотрим, почему некоторые популярные советы с форумов могут окончательно разрушить архитектуру вашей базы данных.
Рассмотрим ситуацию на примере. У нас есть база 1С:Бухгалтерия (версия 3.0.79.21), которая при запуске выдает сообщение «Ошибка формата потока». Очень часто в интернете можно встретить «радикальные» методы решения этой проблемы, связанные с прямым вмешательством в таблицы Microsoft SQL Server. Давайте разберем по шагам, что попытался сделать автор обсуждаемой темы и почему это привело к катастрофическим последствиям.
Сначала был применен скрипт для удаления временно сохраненной конфигурации:
DELETE FROM [ИмяБазы].[dbo].[ConfigSave]
Когда это не помогло, в ход пошел более тяжелый скрипт — полная подмена конфигурации, схемы и параметров из рабочей копии базы:
use ИмяБазы
go
truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
go
insert into [dbo].[Config] select * from [КопияБазы].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [КопияБазы].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [КопияБазы].[dbo].[Params]
go
На первый взгляд конфигуратор открылся, и базу даже удалось выгрузить. Однако при попытке обновиться на следующий релиз, провести тестирование и исправление (ТиИ) или реструктуризацию вылезли критические ошибки:
Const40444.Давайте выясним причину появления ошибок SDBL. Метод с жесткой подменой таблиц Config, DBSchema и Params в SQL является крайне опасным. Так можно делать только в одном случае: если структура таблиц в рабочей базе и в бэкапе абсолютно идентична (не было добавлено ни одного реквизита, справочника или документа).
Платформа 1С генерирует внутренние идентификаторы таблиц динамически. Например, таблица констант может получить имя Const40444, а какое-то поле — Fld41066. Если мы копируем метаданные (таблицу DBSchema) из другой базы, структура, описанная в подмененном словаре, перестает совпадать с реальными физическими таблицами в SQL.
Платформа начинает искать физическую таблицу константы, ориентируясь на скопированные метаданные, но в самой физической базе таблица имеет совершенно другой номер. Нарушается ссылочная целостность словаря метаданных. Внутренние ссылки объектов конфигурации больше не соответствуют физическим типам полей в СУБД. Это классическое следствие подобных «грязных» решений.
Эта ошибка означает, что платформа 1С при попытке чтения данных из базы или временных файлов столкнулась с нарушенной структурой байтов (потоком), которую не может расшифровать. Основные причины:
ConfigSave (сохраняемой конфигурации) или динамического кэша.Рассмотрим подробнее безопасные и эффективные методы, которые следует применять вместо разрушительных SQL-запросов.
Очистка кэша на стороне пользователя — первый шаг. Однако в клиент-серверном варианте закэшированные и поврежденные данные часто хранятся на сервере 1С. Посмотрим, что нужно сделать:
srvinfo/reg_1541/snccntx).USR1CV8).Проанализируем ситуацию: часто зависшие фоновые процессы 1С или процессы СУБД удерживают поврежденные временные файлы. Базовая перезагрузка служб (Агент сервера 1С, SQL Server) высвобождает память и сбрасывает зависшие транзакции, что нередко само по себе решает ошибку формата потока.
Как отметили участники обсуждения, если база работает на SQL, иногда помогает простой метод переподключения: удалите информационную базу в консоли кластера серверов 1С (без удаления самой базы данных в SQL Server!), создайте её заново в консоли 1С и подключите к существующей базе SQL. Это обновит серверные настройки подключения.
Если конфигуратор все-таки запускается, наиболее корректным способом «пересобрать» базу и устранить ошибки потока является выгрузка информационной базы в файл формата .dt. Для этого перейдите в меню Администрирование, выберите пункт «Выгрузить информационную базу», а затем загрузите этот файл в совершенно новую, пустую базу. При такой загрузке платформа заново генерирует таблицы БД и правильно выстраивает индексы без нарушения SDBL.
Если проблема возникла из-за прерванного динамического обновления (когда конфигурация зависла в процессе сохранения), в SQL допускается только один относительно безопасный запрос:
DELETE FROM ConfigSave
Таблица ConfigSave хранит конфигурацию, которая еще не применена к основной базе. Её очистка просто сбросит зависшее обновление. Удаление или усечение других системных таблиц, таких как DBSchema или Config, приведет к потере базы.
Если ошибка формата потока имеет плавающий характер и возникает в файловой многопользовательской базе из-за сетевых сбоев, лучшим решением является развертывание веб-сервера (Apache или IIS). В этом случае пользователи подключаются к базе по протоколу HTTP/HTTPS, что исключает прямую работу компьютеров с файлом базы по протоколу SMB и практически сводит к нулю вероятность разрушения структуры потока.
Если вы, как автор темы, уже выполнили подмену таблиц и получили несовместимость типов полей, восстановить такую структуру практически невозможно. Единственным верным решением в данном случае будет развертывание последнего «живого» бэкапа и перенос всех новых данных (документов и справочников) из сломанной базы в восстановленную при помощи обработок обмена данными (например, Выгрузка-загрузка данных XML). Именно так в итоге и поступил автор темы: перенес все данные в живой бэкап и сделал его основным.