← На главную

При сопровождении типовых конфигураций «1С:Предприятие 8.3», таких как «Зарплата и управление персоналом», администраторы часто сталкиваются с ситуацией, когда текущая версия базы сильно отстает от актуальной. Стандартный путь обновления через файлы .cfu (обновление) требует строгого соблюдения последовательности, указанной в описании к каждому релизу. Однако иногда программа предлагает обновиться сразу «прыжком» через несколько версий. Разберемся подробно, как это работает, безопасно ли это и какие механизмы внутри системы обеспечивают сохранность данных.

Поймем разницу между файлами обновления (CFU) и полным дистрибутивом (CF)

Для начала проанализируем, почему в списке доступных обновлений одни релизы помечены как «(обновление)», а другие выделены жирным шрифтом без этой приписки. Рассмотрим основные различия этих файлов:

1. Файл обновления (.cfu): Это «разностный» файл. Он содержит только те изменения, которые произошли между конкретными версиями. Его преимущество — малый размер, но недостаток — жесткая привязка к исходному релизу. Если ваша версия не входит в список поддерживаемых для этого .cfu, обновиться штатно не получится.
2. Полная конфигурация (.cf): Это полный слепок всей структуры метаданных программы. Когда вы используете .cf для обновления, система заменяет всю структуру конфигурации целиком. Технически это позволяет «перепрыгнуть» неограниченное количество промежуточных релизов.

Как мы видим из обсуждения, если в каталоге шаблонов на вашем компьютере лежит полный дистрибутив новой версии, «Обновлятор» 1С предложит его в качестве доступного варианта, даже если ваша текущая версия официально не заявлена в списке поддерживаемых для перехода на данный релиз.

Разберем механизм работы обработчиков обновления данных

Главное опасение при «прыжке» через релизы — это невыполнение процедур обработки данных. Выясним, почему современные конфигурации на базе БСП (Библиотеки стандартных подсистем) позволяют избегать потери данных при таких переходах.

Рассмотрим алгоритм работы системы при первом запуске после обновления конфигурации в режиме «Конфигуратор»:

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

Когда мы запускаем базу в режиме «Предприятие», система выполняет следующие действия:

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

Таким образом, если вы обновились с версии 3.1.8 сразу на 3.1.9, система увидит, что обработчики для 3.1.8.100, 3.1.8.200 и так далее не выполнялись, и запустит их один за другим в правильном хронологическом порядке. Это и есть ответ на вопрос, почему база продолжает корректно работать и начислять зарплату после «быстрого» обновления.

Проанализируем риски и ограничения

Несмотря на мощный механизм БСП, рассмотрим причины, по которым «прыжки» через релизы могут быть опасны в определенных ситуациях:

1. Цепочка изменений метаданных. Разберем пример: в версии 1 объект назывался Поле_А. В версии 2 его переименовали в Поле_Б. В версии 3 его переименовали в Поле_В. При последовательном обновлении обработчики корректно перенесут данные А -> Б -> В. При прямом переходе с 1 на 3 обработчик из версии 2 может попытаться найти Поле_Б, которого в метаданных версии 3 уже нет (там сразу Поле_В). Однако разработчики типовых конфигураций «1С» обычно сохраняют старые объекты в течение нескольких релизов, помечая их как «Удалить...», что минимизирует этот риск.

2. Огромный объем отложенных данных. В ЗУП 3.1 многие процедуры выполняются в фоновом режиме. Если пропустить 10–20 релизов, объем данных для пересчета может стать критическим. Это приведет к тому, что база будет «тормозить» в течение нескольких дней, пока фоновые задания не завершатся.

3. Узловые релизы. Иногда выходят релизы с кардинальным изменением структуры базы (например, переход на новую версию платформы или масштабная реструктуризация). Такие релизы нельзя пропускать, так как последующие версии могут опираться на уже измененную структуру. Программа обычно блокирует возможность дальнейшего обновления, пока не будет зафиксировано успешное завершение процедур этого узлового релиза.

Рассмотрим по шагам, как правильно выполнить обновление через CF

Если вы решили воспользоваться возможностью быстрого обновления, рекомендуем придерживаться следующего алгоритма:

1. Обязательно создайте резервную копию. При масштабных переходах вероятность программной ошибки выше.
2. В режиме «Конфигуратор» перейдите в меню Конфигурация — Поддержка — Обновить конфигурацию.
3. Выберите пункт Выбор файла обновления и укажите путь к файлу 1cv8.cf (полный дистрибутив), либо выберите его из списка доступных, если он подсвечен жирным.
4. Примите изменения объектов метаданных и обновите конфигурацию базы данных (клавиша F7).
5. Запустите программу в режиме «1С:Предприятие» от имени пользователя с полными правами.
6. Внимание: Дождитесь появления окна «Обновление программы». Не закрывайте его и не выключайте компьютер.
7. После завершения основного этапа перейдите в раздел Администрирование — Обслуживание — Результаты обновления программы.

Выясним, как проверить корректность завершения процедур

Посмотрим на статус обработчиков. В форме «Результаты обновления» вы увидите список всех процедур, которые выполнялись. Если некоторые из них помечены красным значком или статусом «Ошибка», это означает, что «прыжок» через релизы прошел некорректно. В этом случае необходимо:

• Проанализировать текст ошибки в журнале регистрации (событие Обновление информационной базы).
• Если ошибку нельзя исправить вручную, следует восстановиться из копии и пройти путь обновления последовательно, используя файлы .cfu.

Резюме: Обновление через полный .cf файл — это штатная возможность платформы, которая значительно экономит время. Однако она требует от администратора повышенного внимания к этапу выполнения обработчиков в режиме «Предприятие». Если вы не уверены в стабильности релиза или база содержит много доработок, лучше придерживаться рекомендованной цепочки обновлений.