Обновление типовых и доработанных конфигураций «1С:Предприятие 8» — рутинная задача любого администратора или программиста 1С. Когда база отстает от актуального релиза на 5, 10 или 20 версий, последовательное накатывание файлов обновлений (.cfu) превращается в долгую и монотонную работу. На каждом шаге конфигуратор выполняет сравнение метаданных, что на больших базах может занимать часы.
В этот момент у многих специалистов возникает логичный вопрос: а можно ли просто взять файл полной конфигурации (.cf) последнего релиза и обновить базу в один шаг? В этой статье мы подробно разберем техническую сторону этого процесса, выясним, чем это грозит базе данных, как правильно выполнять такое обновление и как работает механизм обновления информационной базы «под капотом».
Для начала проанализируем, чем принципиально отличаются эти два формата файлов:
Существует популярное заблуждение, что в файлах .cfu содержатся некие «особые инструкции» по обновлению базы данных, которых нет в файлах .cf. Это миф. Никаких специальных скриптов или процедур обновления данных внутри самого файла .cfu нет. Вся логика изменения структуры данных в СУБД заложена в саму платформу 1С, а логика заполнения и трансформации данных при запуске программы — в код конфигурации (ОИБ — Обновление Информационной Базы).
Когда мы пытаемся обновить рабочую базу через файл полной конфигурации .cf, у нас в Конфигураторе есть три пути. Рассмотрим их подробнее, так как их путаница часто приводит к катастрофическим последствиям.
Способ №1: Загрузка конфигурации (Конфигурация — Загрузить конфигурацию из файла...)
Этот способ часто используют новички, и он является самым опасным для рабочих баз на поддержке. При выборе этой команды платформа полностью затирает старую конфигурацию и записывает поверх новую структуру из файла .cf.
При этом полностью уничтожается конфигурация поставщика (база снимается с поддержки, пропадает «замок»). Даже если вы загрузили абсолютно типовой .cf той же программы, система больше не считает эту базу типовой. Чтобы вернуть её на поддержку, вам придется делать фиктивное сравнение-объединение с конфигурацией поставщика, что усложняет дальнейшее обслуживание.
Способ №2: Сравнение и объединение (Конфигурация — Сравнить, объединить с конфигурацией из файла...)
Этот метод часто применяют для доработанных баз. Однако при простом сравнении-объединении с файлом .cf основная конфигурация изменится, но конфигурация поставщика останется старой. В результате при следующем типовом обновлении система будет пытаться обновить базу, ориентируясь на старый релиз поставщика, что вызовет хаос в метаданных и ошибки обновления.
Способ №3: Правильный метод обновления через поддержку
Мало кто знает, но штатный механизм обновления прекрасно умеет работать с файлами .cf. Чтобы правильно обновить базу и сохранить поддержку, выполните следующие шаги:
.cf (вместо привычного .cfu).Обновление конфигурации в Конфигураторе — это лишь половина дела (изменение структуры СУБД). Вторая, не менее важная часть — это обработка данных в режиме «1С:Предприятие» при первом запуске после обновления.
За этот процесс в современных конфигурациях отвечает Библиотека стандартных подсистем (БСП) или специализированные модули ОИБ. Выясним, как ведет себя система, если мы «перепрыгнули» сразу через 5–10 релизов с помощью файла .cf.
При запуске в режиме «Предприятие» система считывает текущую версию ИБ из констант (например, Константы.НомерВерсииКонфигурации.Получить()) и сравнивает её с новой версией конфигурации. Программа запускает цепочку обработчиков обновления. Рассмотрим упрощенный пример кода, который наглядно показывает эту логику:
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = "2.0.49.11";
// Обработчики для релиза 2.0.12.2
Если (ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.11" И ТекущаяВерсияИБ <> НоваяВерсияИБ) Тогда
ВыполнитьОбновлениеНаВерсию_2_0_12();
КонецЕсли;
// Обработчики для релиза 2.0.13.5
Если (ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.12" И ТекущаяВерсияИБ <> НоваяВерсияИБ) Тогда
ВыполнитьОбновлениеНаВерсию_2_0_13();
КонецЕсли;
Как мы видим, условия идут последовательно друг за другом (а не через ИначеЕсли). Это означает, что система попытается поочередно запустить обработчики для всех пропущенных релизов по цепочке, чтобы довести данные до актуального состояния. На первый взгляд кажется, что все должно пройти идеально. Но здесь кроется главная ловушка.
Рассмотрим критическую ситуацию, из-за которой обновление через .cf с большим пропуском версий может безвозвратно испортить ваши данные. Представим реальный сценарий изменения метаданных разработчиками «1С» на протяжении трех релизов:
АдресаСтарый, в котором хранятся важные данные клиентов.АдресаНовый. При этом справочник АдресаСтарый не удаляется, а переименовывается в УдалитьАдресаСтарый. В этом же релизе пишется обработчик обновления ОИБ, который при первом запуске переносит все данные из УдалитьАдресаСтарый в АдресаНовый.УдалитьАдресаСтарый из структуры метаданных конфигурации, так как он больше не нужен.Теперь проанализируем, что произойдет при разных сценариях обновления с Релиза №1 до Релиза №3:
Вариант А: Последовательное обновление (как положено)
Вы обновляетесь на Релиз №2. Запускаете «Предприятие». Отрабатывает обработчик обновления, который видит оба справочника, успешно копирует информацию из старого в новый. Затем вы обновляетесь на Релиз №3. Старый справочник удаляется из СУБД, но данные уже в безопасности в новом справочнике. Все работает идеально.
Вариант Б: Обновление в один шаг через CF (с пропуском релиза №2)
Вы берете .cf от Релиза №3 и сразу накатываете его на базу с Релизом №1. Платформа мгновенно перестраивает структуру таблиц СУБД. Поскольку в Релизе №3 справочника АдресаСтарый (или УдалитьАдресаСтарый) физически не существует в метаданных, СУБД безвозвратно удаляет таблицу со всеми данными этого справочника еще на этапе применения конфигурации.
Затем вы запускаете режим «Предприятие». Система видит, что предыдущая версия базы была №1, и начинает по цепочке запускать обработчики обновлений. Доходит очередь до обработчика из Релиза №2, который должен перенести данные из старого справочника в новый. Обработчик обращается к таблице старого справочника, но её уже нет в базе данных! В лучшем случае процесс обновления аварийно прервется с ошибкой СУБД, в худшем — обработчик молча пропустит этот шаг, и вы навсегда потеряете данные по адресам ваших клиентов.
Чтобы минимизировать риски потери данных, фирма «1С» при выпуске обновлений официально указывает требования к исходной версии конфигурации. Если в списке поддерживаемых обновлений для нового релиза нет вашей текущей версии, это значит, что напрямую обновляться нельзя.
Среди сотен версий существуют так называемые ключевые (или переходные) релизы. Это версии, на которых происходят кардинальные изменения в структуре метаданных (например, переход на новые версии БСП, реструктуризация регистров учета НДС или взаиморасчетов). На ключевой релиз обязательно нужно обновиться и запустить базу в режиме «Предприятие», чтобы выполнились все транзакционные и отложенные обработчики обновления, и только после этого можно двигаться дальше.
В современных конфигурациях (таких как БП 3.0, ЗУП 3.1, ERP 2.x) большинство тяжелых обработчиков обновления переведены в статус отложенных. Они выполняются не монопольно при первом старте, а в фоновом режиме порциями с помощью регламентных заданий, пока пользователи уже работают в базе.
Если вы пропустите 15-20 релизов и обновитесь за один шаг через .cf, в очередь выполнения встанут сотни отложенных обработчиков. Некоторые из них имеют строгие взаимные зависимости. Запуск их в один момент может привести к:
Означает ли все вышеописанное, что использовать файлы .cf для обновления вообще нельзя? Нет, использовать их можно и нужно, но с умом.
Если вам необходимо быстро обновить парк из множества однотипных баз, которые сильно отстали от текущих версий, используйте методику последовательного обновления через CF по ключевым релизам: для автоматизации этого процесса можно обновлять несколько баз 1С в автоматическом режиме без участия пользователя.
.cf для этих ключевых точек (Б, В, Г)..cf релиза Б через меню «Поддержка — Обновить конфигурацию». Запустите базу в режиме «Предприятие», дождитесь окончания работы всех обработчиков обновления (включая отложенные).Такой подход позволяет значительно сэкономить время, так как Конфигуратор не будет тратить ресурсы на пошаговое сравнение промежуточных файлов .cfu, но при этом вы гарантируете стопроцентную сохранность данных и корректное выполнение всей логики БСП.
Важное золотое правило: Перед началом любых манипуляций с обновлением конфигурации всегда создавайте резервную копию (архив) базы данных! Даже если вы уверены в своих действиях на 99.9%, всегда остается минимальный шанс столкнуться с ошибкой платформы или логическим сбоем СУБД.