← На главную

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

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

Иллюзия «отката» версии через свойства конфигурации

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

Давайте выясним, почему этот финт является критической ошибкой:

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

Природа ошибок XDTO при загрузке данных из сервиса

Для переноса данных из облака используется архивный файл data_dump.zip. Важно понимать фундаментальное отличие этого архива от привычной резервной копии формата .dt. Файл .dt содержит в себе и конфигурацию, и данные. В то же время data_dump.zip содержит только XML-файлы с самими данными (справочники, документы, константы, движения регистров) и не содержит программный код конфигурации.

Когда вы запускаете загрузку данных из сервиса, платформа выполняет следующие шаги:

1. Платформа считывает структуру метаданных текущей базы приемника и на ее основе динамически строит XDTO-схемы (правила XML-сериализации).
2. Поскольку физическая структура вашей базы осталась на уровне нового релиза, XDTO-схемы ожидают увидеть структуру полей, типов данных и пространств имен, соответствующих именно этой новой версии.
3. Файл выгрузки data_dump.zip был сформирован в облаке под старую версию. В XML-файлах отсутствуют поля, добавленные в новых релизах, либо некоторые типы данных имеют другие типы и структуры.
4. В результате возникает конфликт несоответствия типов. Платформа выдает многочисленные ошибки преобразования данных XDTO. Десериализовать объекты и записать их в базу данных становится невозможно.

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

Правильный и быстрый алгоритм отката чистой базы

Если вам нужно развернуть чистую базу определенной версии, скачивание полного дистрибутива конфигурации (который может весить около 2 ГБ) на низкой скорости интернета — это нерациональная потеря времени. Для решения задачи нам потребуется только файл конфигурации поставщика.

Рассмотрим по шагам правильный алгоритм действий:

1. Получение файла конфигурации (.cf) нужного релиза. Вместо скачивания тяжелого полного дистрибутива скачайте только файл обновления или дистрибутив конфигурации в формате .cf нужного вам старого релиза. Объем такого файла обычно составляет всего 100–300 МБ, что скачивается и передается на компьютер клиента в разы быстрее.
2. Замещение конфигурации в Конфигураторе.
   • Запустите вашу пустую базу новой версии в режиме Конфигуратор.
   • В главном меню выберите пункт Конфигурация — Открыть конфигурацию (если она еще не открыта).
   • Затем перейдите в меню Конфигурация — Загрузить конфигурацию из файла....
   • Укажите путь к скачанному файлу .cf нужной вам старой версии.
   • Система выдаст предупреждение о том, что текущая конфигурация будет полностью заменена, а структура базы данных изменится. Так как ваша база полностью пустая и в ней нет пользовательских данных, смело нажимайте Да.
3. Обновление конфигурации базы данных. Нажмите клавишу F7 (или выберите в меню Конфигурация — Обновить конфигурацию базы данных). Платформа физически перестроит таблицы СУБД, приведя их в точное соответствие с метаданными старого релиза. Теперь ваша база действительно стала чистым полноценным релизом требуемой старой версии.
4. Загрузка данных из сервиса. Запустите базу в режиме «1С:Предприятие». Перейдите в меню Администрирование — Загрузка данных из сервиса и укажите ваш файл data_dump.zip. Процесс загрузки пройдет абсолютно штатно, без ошибок XDTO и повреждения логической целостности базы.

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