Почему не применяются динамические обновления в 1С 8.3 и как это исправить?

← На главную

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

Проблема «невидимых» изменений при динамическом обновлении

Рассмотрим ситуацию: вы вносите правки в модуль документа или отчета, нажимаете «Обновить конфигурацию базы данных», выбираете «Обновить динамически», и Конфигуратор рапортует об успехе. Однако при запуске в режиме «Предприятие» вы обнаруживаете, что старый код продолжает работать, как будто обновлений и не было. Особенно часто это проявляется при переходе с платформы 8.2 на 8.3 или при работе в распределенных информационных базах (РИБ).

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

Решение №1: Отключение автоматического рефакторинга

Как показывает практика опытных разработчиков, основной причиной «зависания» обновлений в версии 8.3 являются настройки автоматического поиска ссылок. Разберем по шагам, как это исправить:

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

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

Решение №2: Очистка кэша на стороне клиента

Если настройки рефакторинга не помогли, велика вероятность, что изменения «застряли» в локальном кэше пользователя. Проанализируем ситуацию: сервер уже отдает новый код, но клиентское приложение продолжает использовать скомпилированные модули из папки %AppData%\Local\1C\1cv8.

Для гарантированной очистки кэша рекомендуется добавить специальный параметр в строку запуска базы в стартере 1С. Рассмотрим, как это сделать:

В списке баз выделите нужную и нажмите кнопку Изменить.
Нажмите Далее до страницы с дополнительными параметрами запуска.
В поле «Дополнительные параметры запуска» впишите следующую команду:

/ClearCache

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

Решение №3: Работа с серверными процессами и таблицей ConfigCAS

Разберем более сложный случай, когда проблема кроется на уровне сервера приложений 1С. При динамическом обновлении платформа создает записи в системной таблице ConfigCAS. Если обновлений было много («наслоение» одного на другое), серверный процесс rphost может запутаться в версиях конфигурации.

В такой ситуации проанализируем следующие действия:

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

Когда динамическое обновление — это действительно «зло»?

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

Состав реквизитов объектов метаданных.
Типы данных существующих полей.
Предопределенные данные.
Структуру регистров.

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

Для пожарных случаев, когда нужно срочно исправить ошибку в коде на базе с 200-300 пользователями, метод из Сообщения 0 (отключение рефакторинга) является спасительным кругом. Однако помните о регламенте: после любого динамического исправления необходимо запланировать технологическое окно для полноценного обновления и перезагрузки сервера.

Рассмотрим пример того, как программно можно отследить необходимость обновления кэша, если вы используете подсистему «Варианты отчетов» или другие механизмы, завязанные на метаданные:


// Пример проверки версии конфигурации в коде
ВерсияКонфигурации = Метаданные.Версия;
Если Константы.ПоследняяОбновленнаяВерсия.Получить() <> ВерсияКонфигурации Тогда
    // Выполнить действия по инициализации новых механизмов
    Константы.ПоследняяОбновленнаяВерсия.Установить(ВерсияКонфигурации);
КонецЕсли;

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