При обновлении типовых конфигураций «1С:Предприятие» (например, «Бухгалтерия предприятия 3.0» или «Зарплата и управление персоналом 3.1») специалисты часто сталкиваются с ситуацией: обновление в режиме Конфигуратора проходит успешно, однако при попытке запустить программу в режиме «Предприятие» система выдает критическую ошибку, требуя более новую версию технологической платформы. Рассмотрим подробно, почему это происходит, как работает механизм проверки и на что нужно обращать внимание при подготовке к обновлению.
Первым делом проанализируем ситуацию, почему Конфигуратор «молчит». Многие ожидают, что система заблокирует применение файла обновления (.cfu или .cf), если текущий движок (платформа) не соответствует требованиям. Однако в архитектуре «1С» эти проверки разделены на два независимых уровня:
Конфигурация существует параметр «Минимальная версия платформы». Конфигуратор сверяет свою текущую версию с этим параметром. Если там указано, например, 8.3.18, а вы работаете на платформе 8.3.18.1208, Конфигуратор сочтет, что условие выполнено, так как мажорная версия совпадает.Проанализируем ситуацию: программная проверка срабатывает только при вызове процедур инициализации сеанса в режиме «Предприятие». Именно поэтому Конфигуратор позволяет обновить структуру данных, но работать в базе не дает.
Выясним причину, по которой проверка перенесена в код. Это сделано для того, чтобы разработчики могли гибко управлять требованиями к платформе без изменения свойств самого объекта метаданных. В БСП за проверку отвечает специальный механизм в модулях обновления информационной базы.
Рассмотрим пример того, как это может выглядеть в коде (упрощенная логика процедур типа ПриНачалеРаботыСистемы):
Процедура ПроверитьВерсиюПлатформы() Экспорт
ТекущаяВерсия = ИнфоБаза.ВерсияПлатформы();
МинимальнаяТребуемая = "8.3.18.1741";
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ТекущаяВерсия, МинимальнаяТребуемая) < 0 Тогда
ТекстСообщения = СтрШаблон("Для работы данной версии конфигурации необходима платформа не ниже %1", МинимальнаяТребуемая);
Отказ = Истина;
// Завершение работы системы с выводом предупреждения
КонецЕсли;
КонецПроцедуры
Этот код выполняется в момент запуска, когда структура базы уже изменена. Именно поэтому автору темы пришлось восстанавливать базу из бэкапа — конфигурация уже «накатилась», и просто так «откатить» её без копии невозможно, так как версия в базе уже обновилась.
Разберем конкретный пример с релизом 3.0.123.26. Этот период (конец 2022 года) был отмечен критическим обновлением систем защиты «1С». Из-за выявленной уязвимости (ошибки в программном лицензировании), компания была вынуждена выпустить экстренные исправления для всех поддерживаемых веток платформ: 8.3.17, 8.3.18, 8.3.20, 8.3.21 и т.д.
В конфигурациях этого периода проверка версии платформы стала «агрессивной». Разработчики намеренно прописали в коде проверку конкретных «безопасных» сборок. Посмотрим на список требуемых версий для того периода:
Если ваша платформа хотя бы на одну цифру ниже указанной в коде БСП, программа не запустится, даже если Конфигуратор позволил применить обновление.
Для того чтобы обновление не превращалось в «развлечение с восстановлением из бэкапа», разработаем стандартный регламент действий перед запуском обновления в Конфигураторе:
.dt. Перед обновлением всегда делайте полную копию папки с базой (для файлового варианта) или бэкап средствами СУБД (для клиент-серверного).Иногда у администраторов возникает соблазн «обмануть» систему, изменив код проверки в общем модуле, чтобы запустить базу на старой платформе. Проанализируем риски такого подхода:
Во-первых, новые релизы конфигураций используют методы платформы, которых просто нет в старых сборках. Например, функции работы с регулярными выражениями, новые параметры HTTP-запросов или изменения в объектах криптографии. При вызове такого метода программа «вылетит» с критической ошибкой Метод объекта не обнаружен.
Во-вторых, несоответствие платформы может приводить к неявным ошибкам при выполнении регламентных заданий или при работе с распределенными информационными базами (РИБ). Данные могут быть повреждены незаметно для пользователя.
В-третьих, в случае с релизами конца 2022 года, использование старой платформы могло привести к блокировке работы из-за ошибки в системе лицензирования, что гораздо серьезнее, чем просто сообщение о несоответствии версии.
Ситуация, когда Конфигуратор не «матюгается» на старую платформу — это не баг, а особенность архитектуры 1С. Основной контроль за средой исполнения сейчас перенесен в программный слой БСП. Рассмотрим это как дополнительный стимул для системного администратора всегда держать платформу в актуальном состоянии и внимательно изучать сопроводительную документацию к каждому релизу.