← На главную

Часто у начинающих специалистов или администраторов баз данных 1С возникает закономерный вопрос: зачем тратить время на последовательное обновление через файлы CFU, если можно взять актуальный файл полной конфигурации CF и сразу обновить базу до нужной версии? На первый взгляд кажется, что это значительно сэкономит время. Однако такой подход таит в себе серьезную опасность для данных. Проанализируем ситуацию подробно и выясним причину, по которой существует жесткий регламент обновления конфигураций 1С.

Разберем понятия: что такое CF и CFU?

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

1. Файл CF (Configuration File) — это полный, самостоятельный слепок структуры конфигурации. Он содержит абсолютно все метаданные (справочники, документы, регистры, модули кода, макеты и так далее). Размер такого файла для современных типовых конфигураций, например, на управляемых формах, может превышать 1 Гигабайт.
2. Файл CFU (Configuration File Update) — это дельта-файл, или файл обновления. Он создается поставщиком решения путем сравнения старой версии конфигурации с новой. В этот файл попадают только измененные данные. Благодаря этому файл CFU весит в десятки, а то и в сотни раз меньше, чем CF.

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

Почему нельзя просто обновиться через CF, перепрыгнув десяток релизов?

Рассмотрим популярный сценарий: у нас есть рабочая база версии 10, а мы хотим получить версию 20. У нас на руках есть полный файл CF 20-й версии. Если мы обновим базу через него, структура метаданных (конфигурация) действительно станет точно такой же, как в версии 20. Конфигуратор отработает, структура таблиц в СУБД обновится. Но что произойдет с самими данными?

Дело в том, что конфигурация не живет отдельно от накопленной информации. За время эволюции от версии 10 до версии 20 разработчики могли кардинально изменить архитектуру учета. Посмотрим на классический пример реструктуризации:

1. В версии 10 существует определенный справочник, в котором пользователи ведут учет.
2. В версии 12 разработчики решают изменить логику и переносят данные из этого справочника в новые сущности (другие справочники или регистры).
3. В версии 15 старый справочник переименовывают, например, в УдалитьЭтотСправочник.
4. В версии 18 справочник физически удаляют из структуры конфигурации.

Если мы пойдем правильным путем (через CFU), обновление пройдет мягко: данные плавно перекочуют из старых таблиц в новые. Если же мы прыгнем с 10 на 20 версию с помощью полного CF, система увидит лишь одно: в старой базе был справочник, а в новой конфигурации его нет. Платформа просто удалит таблицу вместе со всеми данными, которые копились годами! Информация не будет разнесена по новым регистрам, так как промежуточные алгоритмы обработки данных не были запущены.

Обработчики обновления и запуск режима "Предприятие"

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

В каждом промежуточном релизе разработчики пишут специальный программный код миграции. Этот код не выполняется в Конфигураторе. Он запускается только при первом старте системы в режиме "Предприятие". Конфигуратор лишь меняет структуру таблиц (добавляет новые колонки, таблицы), а вот перекладкой данных из одной колонки в другую занимается код, написанный программистами на встроенном языке 1С.

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

1. Применяем файл обновления CFU.
2. Сохраняем конфигурацию базы данных (нажимаем F7).
3. Обязательно запускаем 1С в режиме "Предприятие". Система видит изменение версии, запускает нужные скрипты, переносит данные, заполняет новые реквизиты значениями по умолчанию и выполняет отложенные регламентные операции.
4. Только после успешного завершения всех обработчиков приступаем к накатыванию следующего CFU.

Если вы "накатите" сразу CF 20-й версии, система просто не поймет, что были пропущены версии с 10 по 19. Она не запустит промежуточные скрипты. Новые таблицы останутся пустыми, документы могут перестать проводиться, а отчеты начнут выдавать некорректные цифры.

Внутренние идентификаторы (UUID) и привязка к поддержке

Существует еще одна важная техническая деталь. Платформа 1С:Предприятие связывает объекты метаданных не по их визуальным именам (например, Справочник "Номенклатура"), а по скрытым внутренним уникальным идентификаторам (UUID).

Файлы CFU гарантируют строгую преемственность этих идентификаторов и сохраняют жесткую привязку к "поддержке поставщика". Если неопытный пользователь попытается обновиться через файл CF с использованием механизма "Сравнить и объединить", велика вероятность сбоя идентификаторов. Объекты могут потерять связь с конфигурацией поставщика, начать дублироваться (появится две Номенклатуры) или перезаписаться с ошибками.

Можно ли обновляться "прыжками" с помощью CFU?

Да, можно. Обновление через CFU не означает, что вы обязаны устанавливать строго каждую промежуточную версию (10, 11, 12, 13...). Разработчики формируют файлы CFU таким образом, чтобы они включали в себя изменения сразу для нескольких предыдущих версий.

Узнать допустимый маршрут переходов (с каких версий можно обновиться на текущую) можно в файле UpdInfo.txt, который всегда поставляется вместе с обновлением, или на официальном портале поддержки 1С. Конфигуратор также сам проанализирует выбранный файл CFU и сообщит, подходит ли он к текущему релизу вашей базы.

Когда использование CF действительно необходимо?

Несмотря на то, что для регулярного обновления рабочих баз существует регламентированный путь через CFU, полные файлы конфигурации (CF) официально применяются в ряде сценариев:

1. Создание пустой информационной базы. Если вам нужно развернуть базу для новой организации с нуля (без данных), вы просто загружаете актуальный CF.
2. Восстановление поврежденной конфигурации. Бывают случаи, когда из-за сбоев кэша или отключения питания структура нарушается, и база перестает "видеть" стандартные CFU-обновления. В таком случае базу снимают с поддержки и выполняют команду "Загрузить конфигурацию из файла", указывая полный CF того же релиза, чтобы восстановить целостность.
3. Апгрейд версий или смена локализации. Например, при переходе с Базовой версии программы на версию ПРОФ.
4. Перенос собственных доработок. Программисты активно используют CF-файлы (или cf-расширения), когда работа в тестовой среде завершена, и нужно перенести готовый результат на рабочую площадку предприятия.

Подведем итоги

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

Обновление рабочих баз с данными всегда должно выполняться штатными средствами через файлы CFU, с соблюдением разрешенных маршрутов перехода (согласно UpdInfo.txt) и обязательным запуском программы в пользовательском режиме для корректной отработки программных обработчиков обновления.