← На главную

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

Выясним причину: почему нарушается обратная совместимость?

Рассмотрим внутренние механизмы работы платформы. Основная причина кроется в изменении формата внутреннего представления метаданных. Платформа 1С хранит структуру конфигурации в специальных системных таблицах СУБД (например, в MS SQL Server это таблицы Config, ConfigSave, DBSchema и другие). Начиная с релиза 8.3.17.1823 (и аналогично в ветке 8.3.18), разработчики «1С» внедрили новый алгоритм сериализации данных в поток (stream).

Проанализируем ситуацию по шагам:

1. При первом открытии базы в конфигураторе новой версии или при выполнении обновления конфигурации, платформа автоматически преобразует содержимое таблицы Config в новый формат.
2. Этот процесс происходит «тихо» и часто не требует от пользователя подтверждения изменения структуры хранения.
3. Старые версии платформы (например, 8.3.15 или более ранние сборки 8.3.17) не имеют в своем коде алгоритмов для десериализации этого нового формата.
4. В результате при попытке чтения метаданных старым клиентом возникает исключение, которое пользователь видит как «Ошибка формата потока».

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

Проанализируем проблему с расширениями и выгрузкой данных

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

Также стоит обратить внимание на расширения конфигурации. В новых релизах был существенно переработан механизм контроля целостности расширений и их связи с основной конфигурацией. Изменения затрагивают таблицы Extensions и ConfigCAS. Даже если вы не меняли основную конфигурацию, а просто подключили расширение под новой платформой, структура системных таблиц может измениться безвозвратно для старых версий.

Разберем способ восстановления базы через SQL

Если обновление уже произошло, бэкапа всей базы данных нет, а работать на новой платформе невозможно из-за багов или требований инфраструктуры, остается путь прямого вмешательства в таблицы СУБД. Внимание: любые операции с таблицами SQL должны проводиться только после создания полной резервной копии текущего состояния базы!

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

1. Нам необходимо восстановить метаданные, которые понимает старая платформа. Для этого используются данные из таблицы Config старого бэкапа.
2. Очищаем таблицы текущей («сломанной») базы, которые отвечают за хранение конфигурации:
   Скопировать код

   
   TRUNCATE TABLE Config;
   TRUNCATE TABLE ConfigSave;
   TRUNCATE TABLE DBSchema;
   

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

   
   DELETE FROM ConfigCAS;
   DELETE FROM Extensions;
   

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

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

Рекомендации по безопасному тестированию новых платформ

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

1. Всегда создавайте свежий бэкап непосредственно перед установкой новой платформы, даже если вы просто хотите «посмотреть».
2. При тестировании новых релизов на серверных базах используйте отдельную копию базы данных на тестовом экземпляре SQL-сервера.
3. Помните, что запуск базы в режиме «Предприятие» под новой платформой также может инициировать «тихую реструктуризацию» системных таблиц (например, DBSchema), что заблокирует возможность возврата к старой платформе.
4. Если вы используете командную строку для обновления, применяйте флаг -Force только в крайних случаях, так как он может скрыть ошибки несовместимости, которые проявятся позже в виде битых ссылок или тех же ошибок формата потока.

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