При обслуживании информационных баз 1С периодически возникает необходимость обновить технологическую платформу (например, при переходе с релиза 8.3.9 на 8.3.10). Однако всегда существует риск столкнуться с нестабильной работой новой версии, непредвиденными сбоями или ошибками в отраслевом коде. В связи с этим возникает закономерный вопрос: можно ли безболезненно вернуть прежнюю версию платформы, если база уже была запущена в новой среде, и к каким последствиям это может привести? Разберем подробно технические аспекты совместимости, риски отката и правила создания резервных копий.
Для понимания механизма отката платформы важно четко разделять два независимых понятия: формат физического хранения базы данных и режим совместимости конфигурации.
Многие ошибочно полагают, что возврат на старую платформу можно обеспечить простым изменением свойства в ветке метаданных. Проанализируем, за что отвечает эта настройка. В окне конфигуратора в свойствах корневого объекта конфигурации действительно расположен параметр Режим совместимости. Он управляет поведением встроенного языка, доступностью определенных методов платформы и синтаксических конструкций. Если в конфигурации задана совместимость с версией 8.3.9, платформа 8.3.10 будет эмулировать поведение старого релиза на уровне алгоритмов, однако физическая структура таблиц базы может подчиняться внутренним правилам новой платформы.
Формат физического хранения данных (в файловом варианте это файл 1Cv8.1CD) контролируется непосредственно бинарным ядром платформы. Если новая платформа в процессе работы, реструктуризации или обновления метаданных производит конвертацию формата файла базы данных, более старый релиз платформы физически не сможет его прочитать и завершит работу с критической ошибкой.
В файловом режиме критическим фактором является версия внутреннего формата 1Cv8.1CD. Начиная с версии 8.3.8, в платформе был внедрен формат с поддержкой переменного размера страниц (от 4 Кб до 64 Кб). Релизы веток 8.3.9 и 8.3.10 по умолчанию работают в рамках одного физического формата. Если при переходе на новую версию не запускалась процедура реструктуризации с явным изменением размера страницы, база сохраняет обратную физическую совместимость. Однако простое открытие базы может инициировать обновление служебных таблиц.
Если после возврата на старую платформу база отказывается запускаться, рассмотрим применение штатных сервисных утилит платформы, расположенных в каталоге bin установленной версии 1С:
chdbfl.exe. Запустим эту утилиту перед возвратом на прежний релиз, чтобы убедиться в отсутствии логических и физических разрушений таблиц базы.cnvdbfl.exe. Эта консольная утилита позволяет управлять форматом файла 1Cv8.1CD. Например, если старая платформа выдает ошибку несоответствия структуры, можно принудительно преобразовать формат командой:
cnvdbfl.exe -c -f 8.2.14 "C:\Bases\Accounting\1Cv8.1CD"
Такой вызов приводит структуру файла к базовому формату, который гарантированно прочитается любой платформой ветки 8.3.В варианте «клиент-сервер» ситуация с откатом платформы усложняется из-за взаимодействия службы сервера 1С:Предприятия и СУБД. Выясним, с какими проблемами мы столкнемся при попытке возврата:
srvinfo) модифицируются. Если мы удалим новую платформу и запустим старую службу ragent без восстановления резервной копии каталога srvinfo, сервер не сможет прочитать обновленный реестр баз, и список информационных баз будет утерян.Config и Params. При возврате к старой платформе такие изменения часто приводят к ошибке «Нарушена целостность структуры конфигурации» или ошибкам формата потока.Распространенным заблуждением является надежда на файл выгрузки базы данных (.dt). Механизм сериализации данных при создании выгрузки жестко привязан к версии платформы, в которой выполняется операция. Если мы создадим архив .dt средствами платформы 8.3.10, платформа 8.3.9 при попытке загрузить его может выдать фатальную ошибку несовместимости формата потока. Данные из такой выгрузки окажутся заблокированы.
Сформулируем золотое правило резервного копирования перед любым обновлением платформы:
1Cv8.1CD при полностью остановленных сеансах пользователей..bak для Microsoft SQL Server или дамп средствами PostgreSQL) и обязательно архивируем каталог srvinfo службы сервера 1С.Перед понижением версии платформы обязательно проверим требования самой конфигурации. Например, для «1С:Бухгалтерия предприятия 3.0» разработчики жестко задают минимальный номер релиза платформы в файле поставки ReadMe.txt. Если конфигурация уже была обновлена до релиза, требующего платформу не ниже 8.3.10, запуск на платформе 8.3.9 будет заблокирован программно при инициализации модулей запуска.
Нередко попытка сменить платформу предпринимается в надежде исправить внезапные аварийные завершения программы, такие как системная ошибка BEX (Buffer Overflow Exception). Проанализируем ее истинную природу.
Исключение BEX инициируется встроенным механизмом защиты операционной системы Windows — DEP (Data Execution Prevention), когда приложение пытается исполнить инструкцию из участка оперативной памяти, помеченного как область только для данных. Если такая ошибка возникает не у всех, а лишь у одного-двух пользователей после обновления отраслевого решения (например, «Аренда»), проблема кроется не в платформе 1С, а в локальном окружении рабочих станций. Разберем по шагам, как локализовать и устранить сбой без рискованных манипуляций с платформой:
%LocalAppData%\1C\1Cv8
%AppData%\1C\1Cv8
1cv8c.exe с кодом BEX. Для проверки временно назначим системным принтером по умолчанию виртуальный принтер Microsoft Print to PDF.1cv8c.exe (или 1cv8.exe) в список исключений Data Execution Prevention через панель дополнительных параметров быстродействия операционной системы Windows.