Можно ли обновлять конфигурацию 1С сразу на несколько релизов без промежуточного запуска базы?

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

Техническая суть проблемы: почему платформа позволяет, а логика конфигурации страдает

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

Рассмотрим типовой жизненный цикл реквизитов и структур хранения при развитии типовых конфигураций (например, «1С:Бухгалтерия», «1С:ERP» или «1С:ЗУП»):

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

Проанализируем ситуацию, когда мы накатываем релизы N+1 и N+2 последовательно без запуска предприятия между ними. Структура метаданных сразу становится равной релизу N+2 — старое поле удаляется из таблиц базы данных физически. Когда база наконец запускается в режиме «1С:Предприятие», начинает выполняться процедура обновления от релиза N+1. Этот обработчик пытается обратиться к старому реквизиту, которого в структуре таблиц уже физически нет. В лучшем случае мы получаем аварийное падение с ошибкой Поле объекта не обнаружено, а в худшем — обработчик тихо игнорирует отсутствие источника данных, и важные учетные реквизиты, остатки или движения регистров навсегда остаются пустыми.

Внутренние механизмы БСП и скрытые угрозы «прыжков»

Выясним основные причины, по которым пропуск промежуточных запусков приводит к деградации базы данных:

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

Правильный алгоритм последовательного обновления

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

1. Создание резервной копии. Перед началом любых манипуляций обязательно создаем полный бэкап информационной базы средствами СУБД или через выгрузку в .dt.
2. Определение цепочки перехода. Сверяемся с официальной таблицей порядка обновления фирмы «1С». Обновление возможно осуществлять как через файлы дифференциальных обновлений (.cfu), так и через полные файлы конфигурации (.cf), строго соблюдая минимально допустимую версию источника.
3. Применение конфигурации и реструктуризация. Загружаем файл обновления очередного шага в Конфигураторе и обязательно сохраняем конфигурацию базы данных (F7).
4. Запуск сеанса «1С:Предприятие». Открываем базу под учетной записью с административными правами. Дожидаемся завершения монопольного этапа обновления данных.
5. Контроль отложенных процедур. Переходим в раздел Администрирование — Обслуживание — Результаты обновления программы. Убеждаемся, что список отложенных обработчиков пуст или завершен со статусом 100%. Только после этого переходим к следующему релизу.

Автоматизация и ускорение пакетного обновления

Чтобы не выполнять промежуточные запуски вручную, процесс можно автоматизировать с помощью скриптов командной строки или утилит OneScript.

Посмотрим на пример командного файла для автоматического наката релиза и инициализации процедур обновления БСП без участия пользователя:

REM Шаг 1: Применение файла обновления к конфигурации
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server1C\BaseName" /N "Admin" /P "Password" /UpdateCfg "C:\Updates\1cv8.cfu" /UpdateDBCfg

REM Шаг 2: Запуск предприятия в пакетном режиме для выполнения процедур БСП
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "Server1C\BaseName" /N "Admin" /P "Password" /C "ЗапуститьОбновлениеИнформационнойБазы" /DisableStartupMessages /AppAutoCheckVersion

Если в базе накопился большой объем отложенных данных и регламентное задание выполняется слишком медленно, можно принудительно запустить обработку в реальном времени. Для этого в окне Результаты обновления программы нажимаем гиперссылку с приоритетом выполнения или вызываем программный метод библиотеки:

// Принудительный вызов выполнения всех отложенных процедур обновления БСП
ОбновлениеИнформационнойБазы.ВыполнитьОтложенноеОбновлениеСейчас();

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