Как правильно обновить конфигурацию 1С через хранилище и избежать потери данных

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

Стандартный алгоритм обновления через хранилище

Рассмотрим классический сценарий, который часто применяется в среде разработчиков. Основная идея заключается в том, что все манипуляции по сравнению и объединению проводятся в отдельной тестовой базе (копии), и только результат помещается в хранилище для последующего получения в рабочей базе. Разберем этот процесс по шагам:

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

Проблема пропущенных релизов и обработчиков обновления

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

Рассмотрим пример. Допустим, в релизе 1.0.10 разработчик решил заменить справочник Контрагенты на более универсальный. В релизе 1.0.11 добавляется новый реквизит, а обработчик переносит данные. В релизе 1.0.15 старый реквизит полностью удаляется из метаданных. Если вы обновляетесь с версии 1.0.10 сразу до 1.0.16 через загрузку .cf или хранилище, возможны два сценария:

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

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

Технические нюансы работы с хранилищем

Проанализируем важные детали, которые часто упускаются из виду при работе с механизмом хранилища 1С:

1. Конфигурация поставщика. При обновлении через хранилище передается не только текст модулей и состав полей, но и сама конфигурация поставщика. Когда вы выполняете «Получить из хранилища» в рабочей базе, система обновляет и поддержку. Крайне рекомендуется после получения данных зайти в «Конфигурация — Поддержка — Настройка поддержки» и убедиться, что версия конфигурации поставщика совпала с ожидаемой.
2. Рекурсивный захват. Если в новом релизе появились новые объекты (справочники, документы), обычного захвата корня может быть недостаточно. Используйте захват с флагом «Рекурсивно», чтобы новые объекты корректно «прописались» в иерархии хранилища.
3. Раздувание хранилища. Каждое помещение полной конфигурации увеличивает размер базы хранилища. Если вы планируете обновляться последовательно через 10 релизов, лучше делать это в тестовой базе вне хранилища, а в само хранилище поместить только итоговый результат или 2-3 промежуточных состояния.

Автоматизация процесса через командную строку

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

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Base\Work" /N "Admin" /P "Pass" /ConfigurationRepositoryF "D:\Repository" /ConfigurationRepositoryN "RepoUser" /ConfigurationRepositoryP "RepoPass" /ConfigurationRepositoryUpdateCfg /UpdateDBCfg

Параметр /ConfigurationRepositoryUpdateCfg позволяет получить последние изменения, а /UpdateDBCfg выполняет обновление конфигурации базы данных (аналог F7). Это гарантирует, что все объекты будут получены и приняты корректно.

Чего категорически нельзя делать

Разберем типичные ошибки, которые могут привести к критическим сбоям:

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

Резюме

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