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

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

Рассмотрим подробно причины возникновения этой проблемы, разберем особенности поведения платформы 1С при обновлении релизов и изучим проверенные способы восстановления корректной работы системы.

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

Выясним причину, почему платформа 1С может вести себя так, будто изменилась структура метаданных (хотя менялся только код модуля). Существует несколько основных факторов:

1. Переход на новый релиз или версию платформы. При установке нового релиза платформы (например, при переходе с 8.2.15 на 8.2.16 или обновлении сборки) внутренние механизмы хранения и обработки конфигурации требуют обязательной синхронизации. Первое сохранение конфигурации базы данных на новой платформе всегда требует полного монопольного доступа.
2. Изменение структуры таблиц или предопределенных данных. Динамическое обновление технически невозможно, если выполнялась реструктуризация таблиц СУБД. Сюда относится не только добавление или удаление справочников, документов и реквизитов, но и редактирование состава предопределенных элементов.
3. Зависание флагов незавершенного обновления в СУБД. Если предыдущий сеанс обновления завершился сбоем (аварийное закрытие Конфигуратора, обрыв связи с сервером), в системных таблицах базы данных остаётся служебная информация о неисправном состоянии.

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

Проанализируем порядок действий, необходимых для устранения сбоя и возврата возможности обновлять базу «на лету».

Шаг 1. Проведение первого полного обновления конфигурации БД

Если проблема возникла сразу после обновления самой платформы 1С, необходимо выполнить одно полное обновление информационной базы:

1. Предупредим пользователей и завершим все активные сеансы работы с базой данных.
2. Запустим Конфигуратор в монопольном режиме.
3. Выполним обновление конфигурации базы данных (клавиша F7 или меню Конфигурация -> Обновить конфигурацию базы данных).
4. Дождемся полного завершения процедуры принятия изменений.

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

Шаг 2. Очистка кэша конфигурации у пользователей

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

1. Запустим окно стартера 1С (список информационных баз).
2. Выделим проблемную базу данных и нажмем кнопку Удалить (база удалится только из списка стартера, сам файл или база на сервере останутся нетронутыми).
3. Нажмем кнопку Добавить и повторно укажем путь к информационной базе (или имя сервера и базы СУБД).
4. При повторном добавлении стартер генерирует новый уникальный идентификатор базы, что приводит к формированию чистого кэша при следующем входе.

Решение проблем с динамическим обновлением на уровне СУБД

В случаях, когда Конфигуратор заблокирован из-за сбоя предшествующего обновления в клиент-серверном режиме (SQL), проанализируем состояние системных таблиц. Если в таблице Config зафиксированы фантомные записи незавершенных транзакций, применяют технологию очистки служебных флагов.

Для сброса зависшего состояния выполняется запрос к базе данных на стороне SQL-сервера:

DELETE FROM Config WHERE FileName IN ('commit', 'dynamicCommit', 'dbStruFinal');
DELETE FROM ConfigSave;

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

Особенности динамических обновлений в распределенных базах (РИБ)

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

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

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

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

1. Внешние обработки и отчеты. Печатные формы, логику заполнения документов и новые отчеты целесообразно выносить во внешние файлы (.epf и .erf). Их изменение вообще не затрагивает основную конфигурацию.
2. Расширения конфигурации. В современных версиях платформы 1С внесение правок в программный код и формы реализуется через механизмы расширений. Подключение и обновление расширений, не меняющих структуру данных, происходит безопасно и без остановки работы пользователей.
3. Автоматизированное пакетное обновление. Организация ночных обновлений базы данных с помощью скриптов командной строки позволяет вносить любые изменения в монопольном режиме без создания дискомфорта для сотрудников.