Обновление конфигурации без выгона пользователей: механизм, команды, риски

Динамическое обновление в 1С — это запись изменённой конфигурации в информационную базу без монопольного режима, пока пользователи продолжают работать. Запускается оно в Конфигураторе через Конфигурация → Обновить конфигурацию базы данных (F7): если база занята, платформа предлагает обновить её динамически. Из командной строки то же самое делает ключ /UpdateDBCfg -Dynamic+.

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

Что такое динамическое обновление конфигурации и зачем оно нужно

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

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

Зачем это нужно на практике:

• 🛠 срочно исправить ошибку в модуле проведения, когда в базе сидят 40 человек;
• 🖨 поправить печатную форму или отчёт среди рабочего дня;
• ⏱ не ждать вечера ради изменения, которое затрагивает пару процедур;
• 🌐 обслуживать базы, где люди работают круглосуточно из разных часовых поясов.

Механизм есть и в файловом, и в клиент-серверном варианте. Но по-настоящему востребован он на сервере, где пользователей много и выгнать всех сразу трудно.

Как работает динамическое обновление: старые и новые сеансы

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

Что происходит по шагам:

1. Конфигуратор пытается заблокировать базу монопольно и не может — есть активные сеансы.
2. Платформа спрашивает, выполнить ли динамическое обновление. Вы соглашаетесь.
3. Новая версия записывается в конфигурацию базы данных.
4. Уже открытые сеансы продолжают работать на старой версии: со старыми модулями, формами, составом реквизитов.
5. Любой сеанс, запущенный после обновления, получает новую версию.

Получается, что какое-то время в базе одновременно работают две версии кода. Отсюда и все сильные, и все слабые стороны механизма.

Пример проверки в общем модуле с вызовом с клиента:

Процедура ПроверитьВерсиюКонфигурации() Экспорт
    Если КонфигурацияБазыДанныхИзмененаДинамически() Тогда
        ПоказатьПредупреждение(, "Программа обновлена. Сохраните данные и перезапустите 1С.");
    КонецЕсли;
КонецПроцедуры

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

Рядом стоит функция КонфигурацияИзменена(). Она отвечает на другой вопрос: отличается ли основная конфигурация от конфигурации базы данных, то есть есть ли несохранённые в базу изменения.

Как выполнить динамическое обновление в 1С

В Конфигураторе

1. Откройте базу в Конфигураторе под пользователем с правами администратора.
2. Внесите и сохраните изменения в основной конфигурации.
3. Нажмите F7 или выберите Конфигурация → Обновить конфигурацию базы данных.
4. Если в базе есть другие сеансы, платформа сообщит, что монопольно заблокировать базу не удалось, и предложит динамическое обновление.
5. Ответьте «Да». Если изменения затрагивают структуру хранения, перед записью откроется окно «Реорганизация информации» со списком изменений — просмотрите его и примите.
6. Дождитесь окончания. В нижней части Конфигуратора появится сообщение об успешном обновлении.

Если вместо вопроса Конфигуратор сразу выдаёт ошибку блокировки, значит, эти изменения при активных сеансах записать нельзя. Нужен монопольный режим или фоновое обновление.

Из командной строки

Для ночных скриптов и CI удобнее пакетный запуск Конфигуратора:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER ^
  /S "srv1c\buh" /N "Администратор" /P "пароль" ^
  /UpdateDBCfg -Dynamic+ ^
  /DisableStartupDialogs /Out "C:\logs\update_buh.log"

Что значат ключи:

После запуска обязательно читайте файл из /Out. Код возврата и протокол — единственный способ понять, прошло ли обновление в скрипте.

Фоновое обновление на сервере

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

1cv8.exe DESIGNER /S "srv1c\buh" /N "Администратор" /P "пароль" /UpdateDBCfg -BackgroundStart
1cv8.exe DESIGNER /S "srv1c\buh" /N "Администратор" /P "пароль" /UpdateDBCfg -BackgroundFinish

Первая команда запускает обновление в фоне, вторая завершает его. На финальном шаге платформа применяет изменения, и сеансы должны быть закрыты. Состояние фонового обновления видно в Конфигураторе, если открыть то же окно обновления базы данных.

Плюсы и минусы динамического обновления

Сильные стороны:

• ✅ нет простоя: бухгалтерия продолжает проводить документы;
• ✅ исправление ошибки доходит до людей за минуты;
• ✅ не нужно согласовывать окно обслуживания ради мелочи.

Слабые стороны:

• ❌ в базе одновременно работают старый и новый код;
• ❌ люди, которые не перезапустились, продолжают жить с ошибкой, которую вы уже исправили;
• ❌ долгие фоновые задания, начатые до обновления, доработают по старой логике;
• ❌ сложно сказать, кто из пользователей уже на новой версии.

Когда от динамического обновления лучше отказаться

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

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

Изменение логики, где старый и новый код спорят за одни данные. Пример: вы поменяли алгоритм расчёта себестоимости. Один бухгалтер провёл документ по старому алгоритму, другой — по новому. Расхождение потом ищут неделю.

Удаление или переименование реквизитов, которые используют открытые формы. Старые сеансы обращаются к тому, чего больше нет, и получают ошибки.

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

Закрытие периода , расчёт зарплаты, регламентные операции в разгаре. Если идёт массовая обработка, дождитесь её окончания.

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

Как безопасно делать динамическое обновление: правила практика

Сначала тестовая база

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

Расширения вместо правки основной конфигурации

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

Предупредить людей и заставить перезапуститься

После обновления посмотрите, кто ещё сидит в старых сеансах:

• в консоли администрирования кластера: база → «Сеансы», колонка с временем начала;
• через rac: сначала rac cluster list, затем rac session list с нужными параметрами кластера и базы (точный синтаксис — rac help session).

Всё, что началось раньше времени обновления, работает на старой версии. Попросите этих людей перезапустить 1С.

Регламентные и фоновые задания

Каждый новый запуск регламентного задания стартует новый сеанс и получает новую версию. А вот задание, начатое до обновления и работающее час, доработает по старой логике. Если это критично — дождитесь его окончания или запускайте обновление между запусками.

Фиксировать, что и когда обновили

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

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

Сбои при динамическом обновлении и что с ними делать

Если ни один вариант не подошёл, путь один: дождаться окна обслуживания, закрыть все сеансы и выполнить обычное обновление в монопольном режиме. Оно снимает все вопросы о двух версиях кода в базе.

Частые вопросы