Нужно ли запускать 1С:Предприятие после каждого этапа обновления нетиповой конфигурации?

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

Двухэтапная модель обновления 1С

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

1. Изменение структуры метаданных (Конфигуратор): На этом этапе платформа меняет физическую структуру таблиц в базе данных SQL или файловом варианте. Добавляются новые колонки, удаляются старые реквизиты, меняются типы данных.
2. Выполнение обработчиков обновления (1С:Предприятие): Это программный этап. После того как структура таблиц изменилась, необходимо пересчитать остатки, заполнить новые реквизиты данными из старых или выполнить трансформацию бизнес-логики. Этот код выполняется на языке 1С при первом запуске системы после обновления.

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

Риск «перескакивания» через критические изменения данных

Рассмотрим классическую ситуацию трансформации данных. Представим, что в релизе 1.1 разработчик решил заменить текстовое поле СтарыйАртикул на ссылку на справочник Номенклатура. Процесс в типовых конфигурациях выглядит так:

1. В релизе 1.1 добавляется новое поле НовыйАртикул (ссылка).
2. При запуске «Предприятия» отрабатывает процедура, которая ищет соответствие и заполняет НовыйАртикул на основании данных из СтарыйАртикул.
3. В релизе 1.2 поле СтарыйАртикул помечается на удаление или удаляется физически.

Если мы обновим конфигурацию с версии 1.0 сразу до 1.2 в Конфигураторе, платформа физически удалит колонку СтарыйАртикул. Когда мы, наконец, запустим «Предприятие», обработчик из релиза 1.1 попытается прочитать данные из уже несуществующего поля СтарыйАртикул и либо выдаст ошибку, либо (что хуже) оставит новое поле пустым. Данные будут безвозвратно потеряны.

Работа с Библиотекой стандартных подсистем (БСП)

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

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

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

Поэтому правильный алгоритм выглядит так:

1. Обновление конфигурации в Конфигураторе (F7).
2. Запуск «Предприятия».
3. Переход в раздел Администрирование — Обслуживание — Результаты обновления программы.
4. Обязательное ожидание завершения всех процедур (включая отложенные, если это требуется логикой перехода).

Особенности нетиповых (измененных) конфигураций

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

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

Автоматизация процесса через командную строку

Если вам нужно обновить базу на 10–20 релизов вверх, заходить в каждый вручную утомительно. Мы можем автоматизировать этот процесс, используя параметры запуска 1С. Рассмотрим пример скрипта (бат-файла), который инициирует обновление данных без лишних вопросов:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "C:\Base1C" /N "Admin" /P "Pass" /C ЗапуститьОбновлениеИнформационнойБазы /Visible /DisableStartupMessages

Параметр /C ЗапуститьОбновлениеИнформационнойБазы — это специальный ключ БСП, который говорит системе: «Запустись, выполни все необходимые процедуры обновления и закройся (или покажи результат)». Это позволяет выстроить «конвейер» обновлений, где каждый запуск гарантирует выполнение программной части кода текущего релиза.

Когда все же можно обновлять кумулятивно?

Существует исключение: использование полных файлов конфигурации (.cf) вместо файлов обновлений (.cfu). Если вы перескакиваете через 2–3 мелких релиза внутри одной минорной версии (например, с 3.0.100.10 на 3.0.100.25), разработчики часто включают в последний релиз все обработчики за промежуточные версии. В этом случае код обработчика проверяет текущую версию в базе (например, 3.0.100.10) и последовательно выполняет все функции для версии .15, .20 и .25 за один сеанс работы.

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

Резюме и рекомендации

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

1. Всегда делайте бэкап перед каждым обновлением метаданных.
2. Заходите в приложение после каждого примененного обновления.
3. Проверяйте Журнал регистрации. В нем должны отсутствовать записи с уровнем «Ошибка» от источника ОБНОВЛЕНИЕИБ.
4. Контролируйте статус БСП. Убедитесь, что форма «Результаты обновления программы» сообщает: «Обновление успешно завершено».
5. Не используйте «кумулятивное» обновление для нетиповых баз, если не уверены на 100% в идентичности процедур трансформации данных в промежуточных релизах.

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