При обслуживании баз данных 1С:Предприятие каждый специалист рано или поздно задается вопросом: обязательно ли скачивать десятки файлов обновлений .cfu и устанавливать их по цепочке, или можно взять актуальный полный файл конфигурации .cf и обновить базу за один шаг? Давайте подробно разберем, как платформа обрабатывает оба формата, в чем кроются критические риски потери данных и как правильно выстроить процесс обновления.
Для начала проанализируем саму структуру файлов поставки и обновления. Несмотря на то, что результат успешного обновления визуально выглядит одинаково, механика работы платформы с этими файлами принципиально различается.
.cfu — встроенный механизм проверки версий (по внутренним идентификаторам GUID). Конфигуратор проверит соответствие вашей текущей версии со списком разрешенных версий, зашитых в .cfu. Если вашей версии в списке нет, процесс обновления просто не запустится.Многие ошибочно полагают, что файл .cfu сам по себе как-то по-особенному обрабатывает данные пользователя. На самом деле оба файла работают только с метаданными. Фактическая работа с пользовательскими данными (перенос значений из одного реквизита в другой, заполнение новых справочников) происходит уже в пользовательском режиме (режиме Предприятия) с помощью специальных программных обработчиков.
Почему разработчики 1С и опытные программисты настоятельно рекомендуют обновляться последовательно через .cfu? Разберем классический пример потери данных при обновлении полным файлом .cf с пропуском промежуточных релизов.
Допустим, в конфигурации есть документ с реквизитом СтарыйРеквизит. Разработчик конфигурации решает изменить логику работы и тип этого реквизита. Процесс изменения растягивается на несколько релизов:
НовыйРеквизит. При этом СтарыйРеквизит пока остается в конфигурации (возможно, переименовывается в Удалить_СтарыйРеквизит). Также пишется процедура (обработчик обновления), которая при первом запуске в режиме Предприятия аккуратно перенесет данные из старого реквизита в новый.Удалить_СтарыйРеквизит из дерева метаданных конфигурации.Теперь посмотрим, что произойдет, если мы решим обновить базу со стартового релиза сразу на Релиз 2, используя полный файл .cf.
При применении конфигурации базы данных (нажатии клавиши F7) платформа увидит, что в новом файле .cf нет реквизита СтарыйРеквизит. Она выполнит реструктуризацию таблиц SQL и безвозвратно удалит колонку с вашими данными из базы!
Далее вы запускаете программу в режиме Предприятия. Платформа видит, что версия изменилась, и запускает все накопленные обработчики обновления, в том числе тот, который должен был перенести данные из старого реквизита в новый. Но процедура не найдет исходных данных, так как реструктуризация их уже уничтожила. Итог: безвозвратная потеря пользовательских данных и появление битых запросов.
Рассмотрим еще одну критическую ошибку, которую часто допускают начинающие специалисты. Существует два пункта меню при работе с конфигурацией:
.cf). Это корректный метод "перескока". В этом случае платформа сравнивает идентификаторы объектов (UUID), корректно сопоставляет их и выводит окно сравнения и объединения..cf отличаются от идентификаторов в вашей базе данных (что бывает, если файл выгружен из другой базы), связь между метаданными и физическими таблицами SQL разорвется. База данных будет полностью разрушена.Посмотрим на процесс с точки зрения системных ресурсов. При обновлении типовых "тяжелых" конфигураций (например, 1С:ERP или 1С:Комплексная автоматизация) сразу через множество релизов с помощью .cf, конфигуратор потребляет огромный объем оперативной памяти.
Платформе необходимо построить в памяти дерево текущей конфигурации, дерево новой конфигурации, а также сопоставить тысячи объектов для генерации временных таблиц реструктуризации. Это часто приводит к ошибке «Недостаточно памяти» или исчерпанию места в каталоге временных файлов temp. Использование последовательных небольших .cfu обновлений снижает пиковую нагрузку на сервер.
Сформулируем золотые правила обновления информационных баз 1С, чтобы минимизировать риски:
.cf, чтобы прыгнуть на такую контрольную точку..cf (или крупного .cfu) обязательно запускайте базу в пользовательском режиме. Дождитесь, пока выполнятся все фоновые задания по обработке данных (смена статусов, перенос реквизитов, заполнение новых справочников). Только после того как зеленый индикатор в окне "Обновление версии программы" сообщит об успехе, можно приступать к накатыванию следующего релиза..cfu, собранные измененной конфигурацией поставщика. Обновляйте конфигурацию поставщика стандартно, чтобы следующий программист мог легко отследить ваши доработки через механизм сравнения с типовой конфигурацией.Подводя итог, выясним причину споров в профессиональной среде. Файлом .cf обновлять базу можно, и это существенно экономит время на длительных дистанциях. Однако этот метод требует высокой квалификации и глубокого понимания того, менялась ли структура хранения данных в пропущенных релизах. Если вы не уверены в изменениях архитектуры базы, штатный путь последовательного обновления через .cfu остается самым надежным и безопасным решением.