← На главную

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

Почему конфигурация обновляется через промежуточные релизы

Файлы обновлений с расширением .cfu содержат только дельту — разницу между конкретными релизами конфигурации. Каждый такой файл рассчитан на применение строго к определенному перечню предыдущих версий. Если текущий релиз вашей базы отсутствует в списке поддерживаемых для целевого .cfu, применить такое обновление напрямую невозможно.

Рассмотрим, как формируется цепочка переходов. Допустим, исходная версия базы — 3.0.51.27, а конечная цель — переход на 3.0.53.39. Напрямую установить 3.0.53.39 на версию 3.0.51.27 через файл .cfu нельзя. Потребуется найти связующий релиз ветки 3.0.52, который одновременно поддерживает обновление с 3.0.51.27 и сам входит в список поддерживаемых для 3.0.53.39.

Проанализируем возможные варианты перехода в подобной ситуации:

1. Вариант 1: 3.0.51.27 > 3.0.52.36 > 3.0.53.39
2. Вариант 2: 3.0.51.27 > 3.0.52.39 > 3.0.53.39
3. Вариант 3: 3.0.51.27 > 3.0.52.42 > 3.0.53.39

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

Пошаговый алгоритм последовательного обновления

Разберем регламент выполнения работ по обновлению типовой информационной базы:

1. Создание резервной копии. Перед любыми манипуляциями в Конфигураторе обязательно создаем полную копию базы (выгрузка в .dt для файловых баз или создание бэкапа средствами СУБД для клиент-серверного варианта). Это защитит данные в случае аварийного завершения реструктуризации.
2. Проверка версии платформы. Убеждаемся, что установленная технологическая платформа 1С:Предприятие соответствует минимальным системным требованиям целевых релизов конфигурации. Если платформа устарела, сначала обновляем серверную и клиентские части платформы.
3. Завершение сеансов и блокировка. Блокируем работу пользователей и выполнение регламентных заданий, чтобы избежать блокировок таблиц и повреждения метаданных при реструктуризации.
4. Установка промежуточного обновления. В Конфигураторе открываем меню Конфигурация > Поддержка > Обновить конфигурацию. Выбираем автоматический поиск на сервере или указываем файл первого промежуточного релиза вручную. Применяем изменения к базе данных (клавиша F7). Важно: никогда не используем динамическое обновление при смене релизов, так как меняется структура таблиц.
5. Запуск в режиме «1С:Предприятие» и выполнение обработчиков. После каждого наката промежуточного релиза обязательно запускаем базу в пользовательском режиме. При первом старте выполняются монопольные и фоновые процедуры обновления данных (механизмы БСП). Переходить к установке следующего релиза можно только после того, как все отложенные обработчики успешно завершат свою работу.
6. Повторение цикла. Повторяем процедуру накатывания обновлений и запуска предприятия для каждого последующего релиза цепочки до достижения финальной версии.

Альтернативный вариант: обновление через полный файл конфигурации

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

Рассмотрим особенности этого метода:

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

Перед использованием полного файла .cf обязательно сверяемся с документацией к релизу, чтобы убедиться, что конфигуратор поддерживает прямое обновление с вашей текущей версии.

Что делать при возникновении ошибок после обновления

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

1. Очистка локального кэша. Завершаем работу программы и удаляем содержимое временных папок пользователя операционной системы (каталоги AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8) либо удаляем и заново добавляем строку подключения базы в окне запуска 1С.
2. Тестирование и исправление. В режиме Конфигуратора через меню Администрирование запускаем процедуру Тестирование и исправление информационной базы, выбрав проверку логической и ссылочной целостности и реиндексацию таблиц.
3. Контроль дискового пространства. Для файловых баз убеждаемся, что на диске доступно свободное место в 2–3 раза больше размера файла 1Cv8.1CD, а для клиент-серверных СУБД контролируем размер журнала транзакций.