Как отключить предложение перезапуска программы при динамическом обновлении в 1С

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

Как работает контроль динамического обновления в БСП

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

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

1. ОбщийМодуль.КонтрольДинамическогоОбновленияКонфигурацииВызовСервера — выполняет проверку состояния базы на стороне сервера.
2. ОбщийМодуль.КонтрольДинамическогоОбновленияКонфигурацииСлужебный — содержит серверную служебную логику анализа изменений.
3. ОбщийМодуль.КонтрольДинамическогоОбновленияКонфигурацииСлужебныйКлиент — осуществляет периодический опрос сервера на стороне клиентского приложения и выводит диалоговое окно пользователю.

В клиентском модуле механизм подключен к стандартным периодическим фоновым проверкам, которые запускаются с интервалом в несколько минут.

Способ 1. Переопределение процедуры через расширение конфигурации

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

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

Разберем по шагам, как заглушить вызов или изменить поведение окна:

1. Создадим новое расширение конфигурации или откроем существующее.
2. Добавим в расширение общий модуль КонтрольДинамическогоОбновленияКонфигурацииСлужебныйКлиент.
3. Перехватим обработчик проверки с помощью аннотации &Вместо или изменим логику оповещения.

Рассмотрим пример кода в расширении для полного отключения навязчивого диалога:

&Вместо("ПриВыполненииСтандартныхПериодическихПроверок")
Процедура Расш1_ПриВыполненииСтандартныхПериодическихПроверок(Параметры, ОбработкаПродолжения)
    // Полностью глушим опрос динамического обновления, 
    // чтобы не прерывать работу пользователей диалоговыми окнами.
    Возврат;
КонецПроцедуры

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

Способ 2. Корректировка кода в основной конфигурации

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

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

Почему 1С настойчиво требует перезапуск: технические риски

Выясним причину, по которой разработчики платформы и БСП заложили обязательное требование перезапуска сеансов. Динамическое обновление несет в себе скрытые риски для стабильности системы:

1. Рассинхронизация клиентского и серверного контекста: тонкий клиент удерживает кэш форм и структуру метаданных, считанную при запуске. Если на сервере изменился состав параметров экспортной процедуры общего модуля или реквизитный состав формы, при обращении к серверу возникнет исключение Недостаточно фактических параметров или Метод объекта не обнаружен.
2. Фрагментация памяти и кэша рабочих процессов (rphost): сервер вынужден одновременно поддерживать старые версии сборок для уже запущенных сеансов и новые сборки для входящих подключений. Это приводит к разрастанию кэша, утечкам памяти и потенциальным ошибкам формата потока в таблицах Config и ConfigSave.
3. Непредсказуемое поведение пользователей: пока одни пользователи работают со старыми алгоритмами проведения документов, другие уже проводят документы по новым правилам, что может нарушить целостность учетных данных.

Безопасные альтернативы динамическому обновлению

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

1. Фоновое обновление конфигурации базы данных: штатный механизм платформы 8.3 подготавливает изменения в фоновом режиме без блокировки пользователей. Кратковременная монопольная блокировка требуется лишь на финальном этапе применения изменений (обычно занимает от нескольких секунд до минуты).
2. Применение расширений (патчей): срочные исправления ошибок в коде модулей и формах можно выносить в расширения конфигурации. Установка расширений и исправлений (патчей) выполняется оперативно и значительно мягче воспринимается платформой, чем изменение структуры основной конфигурации.
3. Дополнительные отчеты и обработки: внешние печатные формы, алгоритмы заполнения и специализированные отчеты рекомендуется подключать через справочник ДополнительныеОтчетыИОбработки. Обновление внешнего файла в справочнике применяется мгновенно для всех пользователей без изменения конфигурации.