← На главную

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

Различие в механизмах обновления

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

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

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

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

1. Проблемы с кэшем метаданных: После того как вы обновили расширение на сервере, у активных пользователей на клиентских машинах или в локальном кэше сервера может остаться старая версия метаданных. Это приводит к ошибкам вида Поле не найдено или непредсказуемому поведению программы.
2. Зависание рабочих процессов: В редких случаях попытка динамической подмены кода может привести к некорректной работе рабочего процесса сервера rphost, что потребует его принудительной перезагрузки и вызовет обрыв сеансов.
3. Несоответствие версий: Если код в расширении завязан на данные, которые были изменены, возникает разрыв логики, что чревато записью в базу ошибочных значений.

Важное напоминание про сеансы

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

Рекомендации по безопасной работе

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

1. Используйте штатные завершения: Всегда старайтесь использовать механизм Завершение работы пользователей. Это позволит корректно и вежливо закрыть все сеансы перед внесением изменений.
2. Тестируйте изменения: Никогда не применяйте правки сразу в «боевой» базе. Протестируйте обновление в копии базы данных, чтобы убедиться, что логика работы расширения не нарушает целостность системы.
3. Очистка кэша: При возникновении странных ошибок после обновления расширения, первым делом стоит очистить кэш метаданных на клиенте и, при необходимости, кэш на сервере 1С.

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