Процесс обновления типовых конфигураций 1С:Предприятие — это не только техническое объединение метаданных в Конфигураторе, но и сложная процедура трансформации данных непосредственно в базе. Часто у специалистов возникает соблазн сэкономить время и «накатить» сразу несколько релизов подряд, не открывая пользовательский сеанс. Проанализируем, почему такая практика может привести к фатальным последствиям для базы данных и в каких случаях запуск интерфейса является жизненно важным.
Для начала разберем, из чего состоит процесс обновления с технической точки зрения. Мы должны четко разделять два этапа:
F7.Если мы пропустим второй этап и сразу перейдем к следующему релизу в Конфигураторе, программный код предыдущего релиза никогда не выполнится, а следующий релиз может уже не содержать механизмов для корректной обработки данных «через один» шаг.
В современных конфигурациях (Бухгалтерия 3.0, ЗУП 3.1, ERP 2.5), построенных на базе Библиотеки стандартных подсистем (БСП), механизм обновления стал еще сложнее. Рассмотрим подробнее, как это работает. После запуска интерфейса система инициирует выполнение обработчиков. Они делятся на:
Проанализируем ситуацию: вы обновили конфигурацию на Релиз 2, пропустив запуск интерфейса после Релиза 1. В Релизе 1 был важный обработчик, который готовил данные для Релиза 2. Поскольку база «не знает», что вы перепрыгнули, константа СведенияОбОбновленииИБ может зафиксировать некорректный номер версии. В худшем случае отложенные обработчики из разных релизов выстроятся в очередь, которая не сможет выполниться из-за логических противоречий.
Выясним причину, по которой 1С настойчиво рекомендует соблюдать последовательность. Рассмотрим классический сценарий развлечений разработчиков 1С: переименование объектов. Представим цепочку из трех релизов:
СтарыеДанные.НовыеДанные. Обработчик обновления копирует информацию из СтарыеДанные в НовыеДанные. Старый регистр помечается префиксом Удалить....УдалитьСтарыеДанные полностью исключается из метаданных конфигурации.Если вы обновите Конфигуратор сразу с 10.0 до 10.2 без промежуточного запуска 1С:Предприятие, произойдет следующее: таблицы регистра СтарыеДанные будут физически удалены из SQL-базы, так как в 10.2 их нет. Обработчик из 10.1, который должен был спасти данные, не запустится. В итоге в регистре НовыеДанные будет пусто. Вы потеряли информацию.
Посмотрим на ситуацию, когда обновление производится путем сравнения и объединения с файлом конфигурации (.cf). Это наиболее опасный метод для тех, кто хочет «срезать углы». Разберем пример, упомянутый опытными программистами: реквизит СтавкаНДС.
В какой-то момент в типовых конфигурациях тип этого реквизита менялся с Перечисления на Справочник. При стандартном обновлении через файл .cfu система сопоставляет объекты по внутренним идентификаторам (GUID). При обновлении через «Сравнение и объединение» с .cf легко допустить ошибку:
УдалитьСтавкаНДС, окажется пустым или вообще исчезнет.Именно поэтому запуск интерфейса между релизами позволяет системе корректно «переложить» значения из старых структур в новые до того, как старые структуры будут физически уничтожены следующим обновлением метаданных.
Если ручной запуск интерфейса занимает много времени, проанализируем возможности автоматизации. Для этого можно использовать параметры командной строки. Вместо того чтобы ждать открытия окон и нажимать кнопки, мы можем запустить процесс обновления в пакетном режиме.
Рассмотрим пример команды для запуска базы с автоматическим выполнением обработчиков:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "ПутьКВашейБазе" /N "Админ" /P "Пароль" /C СтартОбновленияИБ /Visible
Параметр /C СтартОбновленияИБ (в некоторых версиях БСП используются другие ключи) заставляет систему сразу начать процедуру обновления данных. Это позволяет программисту автоматизировать цепочку обновлений через скрипты (батники), где последовательно вызывается Конфигуратор для /UpdateCfg и Предприятие для выполнения кода.
Важно понимать: запуск интерфейса — это лишь половина дела. Мы должны убедиться, что обновление завершилось успешно. После каждого этапа необходимо заглядывать в Журнал регистрации. Проанализируем, на что обращать внимание:
Если мы обнаружим ошибку в середине длинной цепочки релизов, нам будет гораздо проще восстановить базу из последнего архива, чем пытаться вычистить логические ошибки спустя месяц после того, как база «вроде бы обновилась».
Разберем упоминание программ вроде «Обновлятор 1С». Такие инструменты автоматизируют именно тот цикл, о котором мы говорим: обновление конфигурации -> запуск предприятия -> ожидание завершения обработчиков -> переход к следующему релизу. Использование подобного софта — хороший способ соблюсти технологию, не тратя личное время на рутинные действия.
Подведем итоги нашего анализа. Можно ли не запускать интерфейс? В редких случаях, когда изменения в релизах минимальны и не затрагивают структуру данных (НСИ), это может «прокатить». Но в промышленной эксплуатации риск слишком велик.
Сформулируем золотые правила обновления:
.cfu.Соблюдение этой дисциплины позволит вам спать спокойно и гарантирует, что через полгода бухгалтер не обнаружит пропажу данных в старых регистрах, которые когда-то были «удачно» пропущены при обновлении.