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

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

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

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

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

Хранилище конфигурации — это централизованное хранилище версий объектов конфигурации, через которое несколько разработчиков согласованно вносят изменения. Каждый объект в хранилище может быть захвачен (заблокирован для редактирования другими) конкретным пользователем. База, подключенная к хранилищу, имеет признак соединения, и многие стандартные операции обновления для неё блокируются.

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

Подготовка: что проверить перед обновлением

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

Далее проверьте, нет ли захваченных объектов у других разработчиков, которые должны попасть в обновление. Если разработчик захватил объект и ушёл в отпуск, не поместив изменения, вы либо ждёте его, либо администратор хранилища принудительно отменяет захват — но тогда незавершённые правки этого разработчика будут потеряны. Согласуйте такие действия с командой.

Обязательный минимум перед стартом:

• свежая резервная копия базы (выгрузка в dt или копия средствами СУБД);
• все пользователи предупреждены и готовы выйти — обновление конфигурации базы данных требует монопольного доступа;
• версия платформы соответствует требованиям нового релиза, если обновляется типовая конфигурация;
• место на диске — при реструктуризации больших таблиц временные файлы могут занимать значительный объём.

Обновление рабочей базы из хранилища

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

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

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

Если обновление из хранилища недоступно (пункт меню неактивен), проверьте, не отключена ли база от хранилища, и не работаете ли вы в режиме, когда конфигурация находится на поддержке с запретом изменений через хранилище. Иногда помогает повторная установка соединения: «Конфигурация — Хранилище конфигурации — Подключиться».

Обновление на новый типовой релиз при подключенном хранилище

Сложный сценарий: конфигурация доработана в хранилище, а поставщик выпустил новый релиз. Здесь есть два рабочих подхода, и выбор зависит от объёма доработок и того, как организована поддержка.

Вариант 1: сравнение и объединение с файлом поставщика

Основная конфигурация остаётся подключенной к хранилищу. Сначала захватите в хранилище все объекты, которые изменятся при объединении — практичнее захватить корень конфигурации целиком, чтобы не пропустить зависимые объекты. Затем выполните «Конфигурация — Сравнить, объединить с конфигурацией из файла», указав cf-файл нового релиза поставщика.

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

Вариант 2: обновление через базу-посредник

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

Сравнение вариантов

Сравнение и объединение напрямую

Подходит при большом объёме доработок в основной конфигурации. Требует ручного разбора дважды изменённых объектов и аккуратного захвата.

База-посредник с типовым обновлением

Подходит при доработках через расширения или минимальных правках. Типовой релиз ставится штатно, риск ошибок ниже, но нужна отдельная база.

Обновление конфигурации базы данных и реструктуризация

После того как основная конфигурация обновлена, нажмите F7. Если изменения затрагивают структуру данных — добавлены или удалены реквизиты, изменены типы, длины строк, составы индексов — платформа покажет окно реструктуризации со списком изменений. Прочитайте его полностью: здесь видно, какие таблицы будут перестроены и не удаляются ли какие-либо данные (например, при удалении реквизита или сужении типа).

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

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

Проверка результата после обновления

Формально успешное завершение обновления не гарантирует, что система работоспособна. Минимальный контроль после накатывания изменений:

Контрольные точки

Как проверить результат

Версия конфигурации

Норма

В «О программе» отображается ожидаемый номер версии

Тревожный признак

Номер версии старый — обновление конфигурации БД не выполнено

Обработчики обновления

Норма

При первом запуске отработали обработчики, статус — успешно

Тревожный признак

Обработчики завершились с ошибками или зависли

Ключевые доработки

Норма

Изменённые объекты работают как задумано

Тревожный признак

Доработки пропали — объект затёрт при объединении

Журнал регистрации

Норма

Нет массовых ошибок после обновления

Тревожный признак

Ошибки при обращении к изменённым объектам

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

Типичные ошибки и как их избежать

Отдельная частая проблема — рассинхронизация версий хранилища между разработчиками. Если один разработчик обновил свою базу до версии 150, а другой продолжает работать с версии 140 и помещает изменения, возможны конфликты и потеря правок. Договоритесь в команде о правиле: перед началом работы каждый обновляется из хранилища до актуальной версии.

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

Полезно вести простой журнал обновлений: дата, номер версии хранилища, кто выполнял, какие объекты были дважды изменены. При спорной ситуации через месяц этот журнал экономит часы разбирательств.

FAQ: частые вопросы по обновлению базы с хранилищем

Почему недоступен пункт «Обновить конфигурацию» через поддержку?

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

Можно ли обновить конфигурацию базы данных без монопольного режима?

Есть динамическое обновление, но оно применимо только к ограниченному набору изменений без реструктуризации. При изменении структуры данных монопольный доступ обязателен. На рабочих базах динамическое обновление лучше не использовать: сеансы со старой версией метаданных могут работать некорректно.

Что делать, если объект захвачен уволившимся разработчиком?

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

Как обновить несколько баз из одного хранилища?

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

Обновление из хранилища прошло, но изменений в базе нет. Почему?

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

Можно ли автоматизировать обновление из хранилища?

Да, конфигуратор поддерживает пакетный режим запуска с параметрами командной строки для обновления конфигурации из хранилища и обновления конфигурации БД. Это используют в скриптах регламентного обновления тестовых баз. Перед внедрением автоматизации обязательно добавьте в скрипт создание резервной копии и проверку кодов возврата.