Динамическое обновление конфигурации 1С без выгона пользователей

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

Новая версия вступает в силу не сразу для всех. Уже открытые сеансы продолжают жить на старой конфигурации до перезапуска, новые сеансы стартуют на новой. Режим подходит для мелких правок кода, форм и макетов. Изменения структуры хранения данных он, как правило, не примет.

Как устроено динамическое обновление в 1С

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

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

Что происходит дальше:

• 🟢 Новые сеансы (вход пользователя, запуск фонового задания, подключение веб-клиента) получают новую версию.
• 🟡 Открытые сеансы работают по старой версии: старый код модулей, старые формы.
• 🔄 Чтобы пользователь увидел правку, ему нужно закрыть 1С и зайти снова.
• 💬 Типовые конфигурации на БСП сами замечают смену версии и показывают пользователю сообщение с предложением перезапустить программу.

Динамическое и обычное обновление: в чём разница

Главное отличие — в том, кому и когда достаются изменения, и какие изменения вообще можно применить.

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

Какие изменения проходят динамически

Обычно без проблем применяются:

• ✏️ правки кода в модулях объектов, менеджеров, общих модулях и модулях форм;
• 🧾 изменения управляемых форм и макетов печатных форм;
• 🧭 команды, подсистемы, состав командного интерфейса;
• 🔐 правки ролей и прав доступа.

Что требует монопольного режима

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

• ➕ новый реквизит или табличная часть у существующего объекта;
• 🔁 смена типа реквизита, длины строки, точности числа;
• 📇 изменение индексирования, измерений регистров, иерархии справочника;
• 🗑️ удаление объектов метаданных.

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

Режимы запуска и условия, при которых режим доступен

Динамический режим работает и в файловой, и в клиент-серверной базе. Варианты запуска три.

Интерактивно из Конфигуратора

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

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

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

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /S "srv01\buh" /N "Админ" /P "пароль" /UpdateDBCfg -Dynamic+ /Out "C:\logs\update.log"

• -Dynamic+ — разрешить динамическое обновление;
• -Dynamic- — запретить его: если монопольный режим недоступен, обновление завершится ошибкой.

Номер версии платформы в пути замените на свой. Полный список ключей смотрите в справке к параметрам командной строки, которая поставляется с платформой.

Через обработчики БСП

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

Если база подключена к хранилищу

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

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

Мини-кейс: исправили печатную форму днём

Бухгалтер жалуется: в счёте на оплату съехала строка с реквизитами банка. Разработчик правит макет, сохраняет конфигурацию и нажимает F7. В базе 12 человек, платформа предлагает обновить динамически, разработчик соглашается.

Через минуту бухгалтер перезаходит в 1С и печатает счёт уже с исправленным макетом. Остальные 11 продолжают работать и получат правку при следующем входе. Ничего в учёте при этом не меняется, потому что макет на данные не влияет. Вот так выглядит правильное применение режима.

Ошибки и неприятности после динамического обновления

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

Почему опасно смешение версий

Представьте: вы исправили алгоритм заполнения документа «Реализация» и обновили базу динамически. Бухгалтер А зашёл после обновления и проводит документы по новому алгоритму. Бухгалтер Б сидит с утра и проводит те же документы по старому.

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

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

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

Когда правка затрагивает структуру или логику учёта, делайте полноценное обновление. Последовательность такая.

1. Сделайте резервную копию. Для клиент-серверной базы — средствами СУБД, для файловой — копией каталога базы или выгрузкой в .dt в нерабочее время.
2. Предупредите пользователей о времени работ хотя бы за 15–20 минут.
3. Заблокируйте начало сеансов. В типовых конфигурациях это делается в разделе Администрирование → Обслуживание, команда блокировки работы пользователей. В клиент-серверном варианте блокировку можно поставить и в свойствах информационной базы в консоли кластера.
4. Дождитесь выхода или завершите сеансы. Принудительное завершение обрывает работу людей: несохранённые документы пропадут. Делайте это после предупреждения и в согласованное время.
5. Проверьте фоновые задания. Регламентные задания тоже держат сеансы. На время работ отключите их блокировкой регламентных заданий.
6. Запустите Конфигуратор с кодом разрешения (параметр /UC, если блокировка ставилась с кодом) и выполните Обновить конфигурацию базы данных.
7. Прочитайте окно реорганизации. Платформа покажет список объектов, которые будут реструктурированы. Если там что-то неожиданное — отмените и разберитесь.
8. Снимите блокировку и зайдите в базу первым. Типовая конфигурация выполнит обработчики обновления.

Производительность после изменений

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

Что помогает:

• 🔁 Перезапуск сеансов. Как только все пользователи перезашли, старая версия больше не нужна и выгружается.
• 🌙 Плановый перезапуск рабочих процессов в нерабочее время. Настраивается в свойствах рабочего сервера и в параметрах перезапуска процессов кластера. Делайте это, когда в базе никого нет: сеансы на перезапускаемом процессе оборвутся.
• 🧹 Очистка клиентского кэша. Если у отдельного пользователя после обновления странно ведут себя формы, запустите его клиент с ключом /ClearCache или очистите кэш вручную через окно выбора баз.

После полноценного обновления с реструктуризацией в клиент-серверной базе нагрузку создаёт другое: у СУБД устаревает статистика по перестроенным таблицам. Запросы к ним могут временно стать медленнее.

-- MS SQL Server: обновить статистику в базе 1С после реструктуризации
USE buh;
EXEC sp_updatestats;

-- PostgreSQL: собрать статистику по всей базе
ANALYZE;

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

Режим удобен, но есть ситуации, где он вредит больше, чем помогает:

• 📅 Закрытие месяца или сдача отчётности. Пользователи массово проводят документы, и расхождение версий ударит сильнее всего.
• 🔄 Есть обмены данными. Сеанс обмена, открытый до обновления, выгрузит данные по старым правилам.
• 🧮 Правка касается расчёта зарплаты, себестоимости, НДС. Часть сотрудников посчитает по-старому.
• 🧩 Типовая конфигурация на поддержке. Ставить релиз поставщика нужно полноценным обновлением с запуском обработчиков.
• 👥 Много пользователей и нет способа их оповестить. Кто-то просидит на старой версии до вечера.

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

Промежуточный вариант — договориться с отделом. Вы обновляете базу динамически в обед, а пользователи по сообщению в рабочем чате разом перезаходят в 1С. Через пять минут все сидят на одной версии, и монопольный режим не понадобился. Сработает, только если людей немного и все на месте.

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