Можно ли обновлять нетиповую 1С через несколько релизов на копии и переносить её в рабочую базу?

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

Основные риски обновления «прыжком» через релизы

Рассмотрим ситуацию, когда конфигурация обновляется не последовательно (1.0.1 -> 1.0.2 -> 1.0.3), а сразу на несколько версий вперед. Основная опасность здесь кроется в механизме работы обработчиков обновления данных. Проанализируем, почему это происходит.

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

• Удаление обработчиков в новых релизах: Разработчики 1С со временем удаляют код обработчиков для очень старых версий, чтобы не загромождать конфигурацию. Если вы обновляетесь с версии 1.0 сразу на 5.0, в коде версии 5.0 может просто не оказаться инструкций о том, как преобразовать данные из формата версии 1.0.
• Цепочки преобразования данных: Рассмотрим пример. В релизе №2 реквизит Пол (булево) перенесли в Перечисление. В релизе №4 старый реквизит удалили. Если вы прыгнули с 1 на 5 релиз, данные из старого реквизита не успеют «перекочевать» в новое перечисление и будут безвозвратно потеряны при удалении поля в структуре базы данных.
• Отложенное обновление: Многие тяжелые операции обработки данных теперь выполняются в фоне. Если база не была запущена в пользовательском режиме на промежуточных этапах, эти фоновые задания не будут выполнены, что приведет к логическим ошибкам в учете.

Методы переноса обновлений: CF против загрузки всей базы

Выясним, какой способ переноса подготовленного обновления из копии в рабочую базу является наиболее безопасным. Рассмотрим два основных подхода.

1. Загрузка конфигурации из файла (CF)

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

• При использовании команды «Загрузить конфигурацию из файла» полностью заменяется конфигурация поставщика. Если ваша база нетиповая и стоит на поддержке с возможностью изменения, это может привести к потере связи с объектами поставщика, и последующие обновления станут крайне затруднительными.
• Если в процессе обновления на копии не запускался пользовательский режим для выполнения обработчиков, то при загрузке .cf в рабочую базу система увидит новую версию и попытается запустить обновление. Но, как мы выяснили выше, «прыжок» может привести к потере данных.

2. Полная замена базы данными из копии (DT или восстановление из SQL)

Этот метод подразумевает, что вы обновляете копию, прогоняете все обработчики, а затем загружаете эту базу вместо рабочей. Это допустимо только в том случае, если в рабочей базе в это время никто не работал. Однако и тут есть подводные камни:

• Идентификатор базы (UID): При замене базы на копию может измениться её уникальный идентификатор. Это приведет к «отвалу» лицензий, сбоям в работе 1С-Отчетности, ЭДО и синхронизации с другими базами (например, обмена между УТ и БП).
• Признак копии: При первом запуске система спросит: «База была перемещена или это копия?». Нужно обязательно выбрать «Перемещена», иначе заблокируются все внешние ресурсы (регламентные задания, обмены).

Технические ограничения и рекомендации по работе с файловыми базами

Разберем ситуацию, когда обновление выполняется в файловом варианте для ускорения процесса. Файловый режим (формат .1CD) действительно работает быстрее на локальных SSD-дисках, но имеет жесткие ограничения:

Проанализируем лимит размера таблиц. В файловой базе размер одной таблицы не может превышать 4 Гб. При обновлении крупных баз (например, 150-200 Гб в SQL), даже если вся база в сжатом виде помещается в файл, в момент реструктуризации одна из таблиц итогов или регистров может временно вырасти и превысить этот лимит. В этом случае база будет повреждена. Для очень крупных баз все операции следует проводить только на SQL-сервере.

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

Рассмотрим наиболее надежную методику, которую рекомендуют опытные специалисты для обновления нетиповых конфигураций:

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

Пример анализа обработчика обновления

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

Процедура ПриОбновленииИнформационнойБазы() Экспорт
    ВерсияПоСтроке = СтандартныеПодсистемыСервер.ВерсияИнформационнойБазы("МояПодсистема");
    
    Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ВерсияПоСтроке, "2.1.3.15") < 0 Тогда
        // Здесь выполняется код по переносу данных из старых полей в новые
        ПеренестиДанныеВНовыйРегистр();
    КонецЕсли;
КонецПроцедуры

Если в новой конфигурации условие СравнитьВерсии будет начинаться, например, с "2.5.0.0", то весь код для более старых версий будет проигнорирован. Именно поэтому важно не допускать слишком больших «разрывов» между версиями без запуска пользовательского режима.

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