Можно ли обновлять типовые конфигурации 1С в Конфигураторе подряд без запуска «Предприятия»?

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

Почему нельзя обновлять через «прыжок» релизов?

Процесс обновления типовой конфигурации — это не просто обновление структуры метаданных. В современных конфигурациях (например, 1С:ERP, УТ 11, БП 3.0) заложена сложная логика миграции данных. Разберем ключевые причины, по которым необходимо запускать 1С:Предприятие после каждого релиза:

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

Как выглядят обработчики обновления в коде

Ранее процесс обновления был более прозрачным для разработчика. В общем модуле можно было увидеть регистрацию обработчиков для конкретных версий. Вспомним пример того, как это выглядело в коде:

Обработчик = Обработчики.Добавить();
Обработчик.Версия = "11.1.2.10";
Обработчик.Процедура = "ПланыВидовХарактеристик.СтатьиАктивовПассивов.УстановитьПризнак";
Обработчик.Опциональный = Ложь;

Обработчик = Обработчики.Добавить();
Обработчик.Версия = "11.1.2.11";
Обработчик.Процедура = "ПартионныйУчетСервер.ИсправитьДвиженияСебестоимости";
Обработчик.Опциональный = Ложь;

Когда вы обновляете систему, 1С:Предприятие считывает эти инструкции и последовательно выполняет их. Если вы «проскакиваете» релиз 11.1.2.10, то логика исправления движений себестоимости в релизе 11.1.2.11 может сработать некорректно, так как ожидаемая структура данных не была приведена в нужный вид.

Особенности фоновых заданий

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

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

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

Рекомендации по безопасному обновлению

Для минимизации рисков мы рекомендуем следовать проверенному алгоритму:

1. Создайте резервную копию: Это обязательное условие перед любым изменением конфигурации.
2. Соблюдайте последовательность: Не пытайтесь перепрыгнуть через промежуточные релизы. Ознакомьтесь с файлом updinfo.txt, который поставляется с дистрибутивом — там указаны обязательные промежуточные версии.
3. Запускайте «Предприятие» после каждого шага: Только так система сможет корректно выполнить код миграции данных.
4. Используйте автоматизацию: Если база требует обновления на множество релизов, рассмотрите использование специализированных инструментов, таких как Обновлятор-1С. Они умеют автоматически контролировать цепочку обновлений и дожидаться завершения всех фоновых процедур.

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