Обновление нетиповой (измененной) конфигурации 1С — это всегда ответственный процесс, требующий понимания внутренних механизмов платформы. Один из часто обсуждаемых методов — подготовка эталонного файла .cf на копии базы с последующей загрузкой его в рабочую информационную базу через пункт «Загрузить конфигурацию из файла». На первый взгляд, это кажется быстрым и удобным способом, но он таит в себе скрытые угрозы. Разберем детально, как работает этот механизм, что происходит с обработчиками обновления и как не допустить критических ошибок.
Прежде всего, проанализируем, чем технически отличается «Загрузка конфигурации» от «Сравнения и объединения». Каждому объекту метаданных (справочнику, документу, реквизиту) платформа присваивает внутренний уникальный идентификатор (Internal ID или GUID объекта метаданных). Эти ID связывают описание объекта в конфигурации с физическими таблицами в базе данных SQL или файловой БД.
Рассмотрим ситуацию: если вы подготовили .cf файл не путем последовательного обновления копии вашей рабочей базы, а, например, «сборкой» из другой базы, идентификаторы объектов могут измениться. При загрузке такого файла через режим «Загрузить конфигурацию из файла» платформа может воспринять существующий справочник как «удаленный», а объект из файла — как «новый». В результате при реструктуризации старая таблица с данными будет безвозвратно удалена, а новая (пустая) создана. Чтобы избежать этого, крайне важно готовить .cf только на актуальной копии рабочей базы, сохраняя преемственность идентификаторов.
Выясним причину, по которой многие опасаются, что обработчики обновления «не отработают». В современных конфигурациях, построенных на базе Библиотеки стандартных подсистем (БСП), за запуск процедур обновления отвечает специальный механизм. Триггером для него является изменение номера версии в свойствах конфигурации.
Проанализируем процесс запуска системы после загрузки нового .cf:
ВерсииПодсистем.ОбновлениеИнформационнойБазы.Таким образом, не имеет значения, как именно вы обновили конфигурацию (через .cfu, через сравнение/объединение или загрузку .cf) — если номер версии изменился, процедуры первого запуска будут инициированы. Однако здесь кроется другая ловушка, связанная с «прыжками» через релизы.
Рассмотрим вопрос «перепрыгивания» через несколько релизов в одном .cf. Технически платформа позволит вам загрузить конфигурацию, которая старше текущей на 10–20 выпусков. Но данные в базе могут стать неактуальными или поврежденными. Почему это происходит?
Разработчики 1С (особенно в таких конфигурациях, как ERP, УТ 11 или БП 3.0) регулярно проводят «чистку» программного кода. Код обработчиков обновления, который конвертирует данные для старых релизов, удаляется из конфигурации через 2-3 года. Если вы обновляетесь с версии 2021 года сразу на версию 2024 года, в новом .cf просто может не оказаться процедур, способных обработать ваши «древние» данные. В итоге конфигурация обновится, но логическая структура данных (заполнение новых регистров, перенос реквизитов) останется незавершенной.
Для предотвращения этой ситуации разберем правильный алгоритм действий:
Посмотрим на ситуацию со стороны расширений конфигурации. Загрузка целого .cf — это «жесткая» операция. Если в расширениях установлены флаги «Проверять при подключении» для измененных объектов, то при малейшем несовпадении типов или структуры в основном .cf расширение будет отключено. После каждой загрузки .cf в рабочую базу необходимо зайти в «Управление расширениями» и убедиться, что все они находятся в активном статусе.
Отдельно отметим опасность динамического обновления (обновление «на лету» при наличии пользователей). Для нетиповых конфигураций с изменением структуры данных это категорически запрещено. Загрузка .cf подразумевает полную замену конфигурации базы данных. Если в этот момент в базе есть активные фоновые задания или «зависшие» сеансы, это может привести к повреждению служебной таблицы Config, что потребует сложного восстановления через утилиту chdbfl.exe или SQL-запросы.
Подводя итог, выстроим пошаговую стратегию безопасного обновления:
.cf файл из обновленной и протестированной копии..dt или бэкап SQL).Рассмотрим пример программной проверки версии подсистемы, которая может помочь вам понять, на каком этапе находится обновление:
// Пример получения версии установленной конфигурации через БСП
ВерсияПриложения = СтандартныеПодсистемыСервер.ВерсияПрограммы();
Сообщить("Текущая версия конфигурации: " + ВерсияПриложения);
// Проверка необходимости обновления данных
Если ОбновлениеИнформационнойБазы.НеобходимоОбновлениеДанных() Тогда
Сообщить("Требуется запуск обработчиков обновления!");
КонецЕсли;
Соблюдение этой методики гарантирует, что все связи объектов будут сохранены, а данные корректно преобразованы под требования нового релиза. Помните, что использование .cf — это лишь способ доставки кода, а основная работа по актуализации данных всё равно происходит внутри механизмов БСП при первом запуске системы.