← На главную

При обслуживании доработанных конфигураций 1С, находящихся в режиме «Редактируется с сохранением поддержки», процесс обновления через несколько релизов подряд отнимает много времени. На каждом шаге разработчик вручную разрешает конфликты в модулях, на формах и сопоставляет объекты. Возникает закономерный вопрос: можно ли выполнить все эти действия на тестовой копии, сохранить итоговый файл .cf и быстро применить его к рабочей базе через пункт меню «Конфигурация» → «Загрузить конфигурацию из файла…»?

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

Как работает загрузка файла конфигурации и почему это возможно

Метод «Загрузить конфигурацию из файла…» в случае нетиповой базы полностью заменяет как основную конфигурацию, так и конфигурацию поставщика на те, которые содержатся в загружаемом файле. Это кардинально отличается от операции «Сравнить и объединить с конфигурацией из файла».

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

1. Перенос актуальной поддержки: В сохраненном файле .cf уже присутствует обновленная конфигурация поставщика целевого релиза, а также корректно расставлены все правила поддержки (замки) для типовых и измененных объектов. При загрузке в рабочую базу конфигурация поставщика автоматически обновится до нового релиза.
2. Идентичность внутренних идентификаторов (UUID): Поскольку обновление поэтапно готовилось на актуальной копии именно этой рабочей базы, все существующие объекты метаданных (справочники, документы, реквизиты, регистры) имеют строго совпадающие внутренние системные идентификаторы (GUID). Платформа воспринимает их как «родные», не создавая дублей таблиц и не удаляя существующие данные.
3. Минимизация времени простоя: Обновление рабочей базы сводится к быстрой замене структуры метаданных и запуску обработчиков, исключая многочасовую ручную работу программиста в монопольном режиме.

Ключевые риски и подводные камни прямого обновления через .cf

Несмотря на техническую реализуемость, бездумная загрузка .cf в рабочую базу несет критические риски. Проанализируем основные опасности, с которыми можно столкнуться.

1. Двухэтапная миграция данных в подсистемах БСП

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

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

2. Изменения в рабочей конфигурации во время подготовки

Команда «Загрузить конфигурацию из файла…» выполняет полную перезапись метаданных. Если в то время, пока вы настраивали обновление на копии, в рабочей базе кто-то правил модули, добавлял новые реквизиты или изменял состав метаданных, эти доработки будут безвозвратно уничтожены.

3. Слишком большой разрыв между версиями

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

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

Разберем по шагам безопасный алгоритм обновления доработанной базы методом накатывания подготовленного файла конфигурации.

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

Альтернативные способы упрощения будущих обновлений

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

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

Таким образом, обновлять рабочую базу через команду «Загрузить конфигурацию из файла…» можно, и это стандартная практика. Главное условие — подготовка файла на точной и актуальной копии рабочей базы, обязательный предварительный запуск обновления данных на тестовом контуре и детальный контроль окна реорганизации метаданных.