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

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

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

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

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

Сценарий знаком каждому администратору:

1. Разработчик правит конфигурацию и нажимает Конфигурация → Обновить конфигурацию базы данных (F7).
2. Платформа не может установить монопольный режим, потому что в базе есть сеансы.
3. Она предлагает выполнить динамическое обновление. Разработчик соглашается.
4. Новые сеансы открываются уже с новой конфигурацией. У тех, кто работал, остаётся старая, а в клиенте появляется сообщение, что конфигурация изменена и программу нужно перезапустить.

Из командной строки то же самое управляется ключом /UpdateDBCfg: параметр -Dynamic+ разрешает динамическое обновление, -Dynamic- запрещает.

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /S"srv1c\buh" /N"Администратор" /P"пароль" /UpdateDBCfg -Dynamic-

С -Dynamic- пакетное обновление при занятой базе просто не выполнится — для ночных регламентов это честнее, чем молча обновиться динамически.

Когда платформа сама откажет

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

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

Две версии кода на одних данных: где страдает целостность

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

Чем это оборачивается на практике:

• 🔀 Разное проведение. Изменили алгоритм движений документа. Бухгалтер в старом сеансе проводит документ по-старому, коллега в новом — по-новому. За один день в регистрах оказываются записи, сформированные разными алгоритмами.
• 🧩 Новые реквизиты не заполняются. Добавили обязательный реквизит и проверку заполнения. Старый сеанс о нём не знает: форма его не показывает, проверка не срабатывает, документ записывается с пустым значением.
• ⏱️ Регламентные задания уже на новой версии. Фоновые и регламентные задания стартуют новыми сеансами, поэтому выполняют новый код. Пользователи в это время работают со старым. Обмен или закрытие месяца в фоне может обработать данные, которые старый код только что записал «не по новым правилам».
• 💾 Кэш повторного использования. Значения, которые общие модули с повторным использованием возвращают в рамках сеанса, остаются старыми. Изменённые константы и настройки старый сеанс может не увидеть до перезапуска.

Нагрузка на сервер и скорость работы после «динамики»

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

Что заметит администратор кластера:

• 📈 Растёт память rphost. Пока в базе живут сеансы старой и новой версии, рабочий процесс держит обе. Несколько динамических обновлений за день без перезапуска пользователей — несколько наборов кэшей.
• 🐢 Первые вызовы медленнее. После обновления серверные модули компилируются заново, а кэши строятся с нуля. Первые открытия форм и проведение документов в новых сеансах идут заметно дольше обычного.
• ⏸️ Пауза в момент применения. Сама запись конфигурации в базу на время блокирует часть операций. В большой базе с активной работой пользователи почувствуют «подвисание».

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

Типовые конфигурации и БСП: почему «на горячую» обновлять нельзя

Типовые конфигурации — Бухгалтерия 3.0, ЗУП 3.1, УТ 11 и другие — построены на Библиотеке стандартных подсистем (БСП). Для БСП смена релиза — это не только новые модули, но и обработчики обновления информационной базы: они переносят и пересчитывают данные под новую версию.

Где ломается связка с динамическим обновлением:

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

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

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

Расширения конфигурации и динамическое обновление

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

Расширение применяется при старте сеанса. Загрузили или изменили расширение в режиме 1С:Предприятие — работающие пользователи продолжат без него до перезапуска. Картина та же: часть пользователей с доработкой, часть без.

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

Что проверять после обновления основной конфигурации:

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

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

Отладка — область, где динамическое обновление создаёт больше всего лишней работы.

Типичные ситуации:

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

Как сократить время на поиск:

1. Перед разбором ошибки уточните у пользователя, перезапускал ли он программу после обновления. Если нет — пусть перезапустит и повторит.
2. Посмотрите время начала сеанса пользователя в консоли кластера и сравните со временем обновления.
3. Отлаживайте только на сеансах, открытых после обновления.

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

Права доступа и исправления, которые «не доехали»

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

Что это значит:

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

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

Как обновлять конфигурацию 1С безопасно

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

Какой способ выбрать

Фоновое обновление из командной строки управляется параметрами -BackgroundStart и -BackgroundFinish к /UpdateDBCfg: подготовку реструктуризации можно запустить днём, а короткое завершение — вечером.

Порядок действий для изменений с риском

1. Сделайте резервную копию: выгрузку .dt или копию средствами СУБД.
2. Проверьте конфигурацию (Конфигурация → Проверка конфигурации) и расширения.
3. Установите блокировку сеансов на время работ — в консоли кластера в свойствах информационной базы или средствами БСП в типовых конфигурациях.
4. Завершите оставшиеся сеансы. Пользователи должны знать о времени работ заранее: незаписанные документы будут потеряны.
5. Обновите конфигурацию базы данных в монопольном режиме.
6. Для типовых конфигураций — запустите программу под администратором, чтобы выполнились обработчики обновления.
7. Снимите блокировку и проверьте работу ключевых операций в новом сеансе.

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