При администрировании и доработке старых конфигураций на платформе 1С:Предприятие 8 специалисты часто сталкиваются со специфическими трудностями. Одним из таких классических кейсов является переход с версии ПРОФ на версию КОРП (на примере конфигурации Зарплата и Управление Персоналом 2.5), а также сопутствующие сбои при выполнении отложенных обработчиков обновления информационной базы. В данной статье мы подробно разберем, почему платформа требует снятия конфигурации с поддержки перед загрузкой файла, как правильно обходить «железные замки» поставщика и каким образом реанимировать систему, если процесс обновления завершился аварийно.
Рассмотрим стандартный сценарий перехода с ЗУП ПРОФ на ЗУП КОРП в рамках одной редакции. Инструкция предписывает обязательное снятие конфигурации с поддержки перед выполнением операции загрузки файла 1cv8.cf. У многих разработчиков возникает логичный вопрос: для чего выполнять это действие, если конфигурация КОРП всё равно будет загружена полностью и заменит собой старую?
Выясним причину этого требования. В системе 1С существует понятие «объектов поставщика», которые по умолчанию находятся на строгой поддержке без возможности редактирования. В интерфейсе Конфигуратора такие объекты помечены желтым значком замочка (так называемый «железный замок»).
Когда мы пытаемся выполнить полную замену конфигурации через меню Конфигурация — Загрузить конфигурацию из файла, платформа осуществляет посегментную замену метаданных. Если в текущей базе присутствуют объекты, закрытые для изменений, платформа заблокирует операцию загрузки, выдав ошибку нарушения прав доступа или изменения структуры. Платформа защищает конфигурацию поставщика от случайного разрушения или несанкционированного изменения структуры данных.
Для обхода этого ограничения существует два пути:
1cv8.cf.Важный нюанс: не стоит бояться полного снятия с поддержки на шаге 4. Как только вы выполните шаг 5 и загрузите официальный файл 1cv8.cf версии КОРП, платформа автоматически определит, что данный файл является конфигурацией поставщика. База данных снова вернется на полноценную поддержку обновлений от «1С», но уже по линии КОРП.
Проанализируем важный практический совет, касающийся дальнейшей эксплуатации базы. Некоторые разработчики привыкают держать конфигурации в состоянии «с возможностью изменения каждого объекта». Это серьезная методическая ошибка.
Если объект метаданных снят с замка (даже если его код и свойства не менялись вручную), при каждом последующем обновлении система будет тратить колоссальные ресурсы на операцию сравнения и объединения этого объекта с новой конфигурацией поставщика. Для оптимизации скорости обновления и минимизации рисков деления кода рекомендуется держать на поддержке с возможностью изменения только те объекты, которые действительно подверглись кастомизации. Все остальные типовые объекты должны быть закрыты на «замок».
Перейдем ко второй проблеме, с которой часто сталкиваются специалисты при обновлении крупных или доработанных баз данных: сбой выполнения отложенных обработчиков обновления информационной базы.
Симптомы проблемы: при запуске в режиме «Предприятие» система выдает сообщение «Не удалось обновить конфигурацию», процесс прерывается, а в Журнале регистрации фиксируется неинформативная ошибка вида ERR: возврат 1.
Разберем по шагам, как локализовать и устранить эту неисправность в старых конфигурациях типа ЗУП 2.5.
Часто для принудительного старта процедур обновления пытаются использовать параметры запуска командной строки, но сталкиваются со следующей ошибкой: система сообщает о неверных командах. Посмотрим на типовую ошибку в синтаксисе ключа:
Неправильно: /с ЗапускОбновленияИнформационнойБазы
Правильно: /C ЗапуститьОбновлениеИнформационнойБазы
Обратим внимание на критически важные детали:
Поскольку конфигурации поколения ЗУП 2.5 опираются на классические механизмы контроля версий, главным триггером запуска процедур обновления выступает константа НомерВерсииКонфигурации. Система сравнивает значение этой константы с жестко прописанным номером версии в коде текущей конфигурации.
Если в процессе обновления произошел сбой, константа может записаться некорректно, либо алгоритмы обновлений зависнут в промежуточном состоянии. Чтобы обмануть систему и заставить её выполнить повторный «первый запуск» обновления, выполним следующие действия:
Пример программного кода для сброса версии конфигурации:
// Сброс версии конфигурации для повторного запуска обновлений
Процедура СброситьВерсиюКонфигурации() Экспорт
ТекущаяВерсия = Константы.НомерВерсииКонфигурации.Получить();
Сообщить("Текущая записанная версия: " + ТекущаяВерсия);
// Устанавливаем заведомо меньшую версию
Константы.НомерВерсииКонфигурации.Установить("2.5.120.1");
Сообщить("Установлена фиктивная версия для перезапуска обновлений.");
КонецПроцедуры
После записи этой константы закроем Конфигуратор и запустим базу в режиме «Предприятие» монопольно. Система обнаружит разницу версий и инициирует повторный запуск всех обработчиков обновления.
Хотя ЗУП 2.5 уже снята с поддержки, понимание механизмов обновления крайне важно, поскольку современные программные продукты (ЗУП 3.1, ERP, Комплексная автоматизация) используют схожие принципы, но управляются через Библиотеку стандартных подсистем (БСП). Рассмотрим, как решать аналогичные проблемы с зависанием отложенных обновлений в современных базах.
В БСП запуск и контроль обновлений разделен на монопольную часть и отложенную (которая может выполняться в фоновом режиме при работе пользователей). Если один из фоновых обработчиков падает с ошибкой, пользователи могут потерять доступ к объектам программы.
Разберем методы администрирования таких ситуаций в БСП:
Перейдем в раздел Администрирование — Обслуживание — Результаты обновления программы. В открывшейся форме мы увидим список всех незавершенных или завершившихся аварийно обработчиков. Здесь мы можем нажать кнопку Перезапустить отложенное обновление.
В современных конфигурациях вместо одной константы используется регистр сведений ВерсииПодсистем. Если нам нужно инициировать повторный прогон обновления для конкретного блока метаданных, мы находим в этом регистре нужную запись (например, подсистему «Зарплата Кадры») и вручную или программно понижаем номер ее версии.
Информация о каждом обработчике обновления хранится в регистре сведений ОбработчикиОбновления (или в таблице очереди отложенных обработчиков). Если конкретная процедура обновления содержит ошибку в коде, которая не критична для текущего учета, но блокирует работу всей системы, администратор может принудительно изменить статус этой записи в регистре с «Ошибка» или «Выполняется» на «Выполнен».
Для повторного запуска сбойной процедуры статус можно сбросить на значение «Не запускался».
Если база данных намертво блокируется при запуске заставкой «Не удалось выполнить обновление» и сразу же закрывается, не давая зайти в интерфейс администратора, мы можем применить экстренный метод обхода:
ОбработчикиОбновления).Таким образом, понимание внутренней структуры хранения версий конфигурации и правил работы платформы с объектами поставщика позволяет оперативно решать любые нештатные ситуации при обновлении баз данных семейства 1С:Предприятие.