← На главную

При обслуживании информационных баз 1С часто возникает ситуация, когда конфигурация отстает от актуального выпуска на несколько месяцев или даже лет. Среди специалистов ведутся споры: можно ли сэкономить время и разом загрузить итоговый файл конфигурации .cf, или же необходимо последовательно накатывать каждый промежуточный файл обновления .cfu?

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

Разберем механику работы подсистемы обновления БСП

Многие разработчики полагают, что при загрузке итогового файла .cf система 1С сама корректно распознает пропущенные релизы и выполнит все необходимые алгоритмы конвертации данных. Отчасти это правда: в типовых конфигурациях запуск обработчиков данных отвечает Библиотека Стандартных Подсистем (БСП).

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

Однако успешность выполнения этого процесса зависит от того, как именно менялась структура данных СУБД между релизами.

Проанализируем риски прямого обновления через загрузку файла .cf

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

1. Физическое удаление объектов СУБД и потеря данных. Представим распространенную ситуацию: в промежуточном релизе разработчики 1С решили перенести данные из Реквизит1 в новый Реквизит2. Для этого Реквизит1 переименовывается в Удалить_Реквизит1, а в БСП закладывается обработчик, который при запуске переносит значения. В последующем релизе реквизит Удалить_Реквизит1 окончательно удаляется из метаданных. Если мы сразу загружаем итоговый .cf, платформа на уровне СУБД удаляет столбец Удалить_Реквизит1 еще до запуска режима «1С:Предприятие». Когда после этого БСП пытается выполнить обработчик переноса данных из пропущенного релиза, она обращается к реквизиту, которого физически уже нет в базе, что приводит к критической ошибке или полной потере информации.
2. Изменение кода модулей и БСП. Если за время пропуска релизов версия БСП обновилась на несколько редакций (например, с 2.1 до 2.4), процедуры обновления из старых релизов могут обращаться к функциям экспортных модулей, которые были переименованы или удалены в новой версии библиотеки. Это вызывает синтаксические ошибки и остановку выполнения обработчиков.
3. Сброс конфигурации поставщика. Использование операции Конфигурация — Загрузить конфигурацию из файла полностью перезаписывает дерево метаданных и снимает настройки поддержки. Если база была доработана и находилась на поддержке с возможностью изменения, прямая загрузка .cf приведет к затиранию доработок или к потере связи с базовой конфигурацией поставщика. В дальнейшем накатить стандартный файл обновления .cfu станет невозможно.
4. Нагрузка на сервер и блокировки. При пропуске десятков релизов БСП формирует огромную очередь отложенных (фоновых) обработчиков. Их одномоментный запуск после входа пользователей создает колоссальную нагрузку на СУБД и приводит к взаимоблокировкам (deadlocks) таблиц.

Выясним, как работает штатный механизм автообновления 1С

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

Алгоритм работает по следующей схеме:

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

Такой подход гарантирует сохранность конфигурации поставщика и верное построение диффов, однако риски реструктуризации СУБД (описанные в первом пункте) частично сохраняются и при пакетном применении .cfu, если между релизами с удалением объектов не выполнялся запуск режима «Предприятие».

Сформулируем правильный порядок обновления устаревших баз

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

1. Изучим файл порядка обновления. В каждом дистрибутиве содержится файл 1cv8upd.htm. Проанализируем список релизов, с которых разрешен прямой переход на данную версию.
2. Используем накопительные релизы. Фирма 1С периодически выпускает узловые (кумулятивные) релизы. Не обязательно ставить каждый мелкий выпуск — достаточно двигаться по ключевым опорным точкам, указанным в порядке обновления.
3. Обновляем конфигурацию поставщика корректно. Если база доработана, используем режим Конфигурация — Поддержка — Обновить конфигурацию с выбором файла .cf или .cfu, но не используем команду загрузки конфигурации.
4. Контролируем запуск режимов предприятия при смене редакций. При переходе между крупными редакциями (например, при смене версии БСП или переходе с УТ 11.2 на УТ 11.4) обязательно запускаем базу в режиме «1С:Предприятие» и дожидаемся полного завершения работы всех монопольных и отложенных обработчиков обновления.
5. Запускаем процедуру обновления монопольно. Чтобы исключить вход пользователей до окончания конвертации данных, используем параметр запуска командной строки: 1cv8.exe ENTERPRISE /F "C:\Bases\Trade" /C СтартОбновленияИнформационнойБазы

Вывод: Обновление через прямую загрузку .cf на типовых конфигурациях с большим пропуском релизов — это высокорискованная операция, которая может привести к неявной потере данных и повреждению структуры поддержки. Самым надежным решением остается последовательное движение по ключевым релизам с обновлением через конфигурацию поставщика.