Когда можно обновлять 1С динамически

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

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

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

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

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

Технически платформа хранит две версии метаданных: старую, с которой продолжают работать открытые сеансы, и новую, которую получат пользователи при переподключении. Это возможно только тогда, когда физическая структура таблиц в СУБД не меняется — иначе старые сеансы начали бы писать данные в несовместимый формат.

В файловом режиме динамическое обновление тоже доступно, но там выше риск конфликтов: файловая база не имеет серверного слоя, который координирует параллельную работу. На клиент-серверных развёртываниях (MS SQL, PostgreSQL) механизм работает надёжнее.

Какие изменения допускают динамическое обновление

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

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

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

Когда динамическое обновление невозможно

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

К блокирующим изменениям относятся:

• добавление, удаление или переименование реквизитов, измерений, ресурсов, табличных частей;
• изменение типа или длины существующих полей;
• добавление новых объектов метаданных, создающих таблицы (справочников, документов, регистров);
• изменение состава регистраторов регистров, режимов проведения, признаков учёта;
• изменение планов обмена — состава объектов, входящих в подписки.

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

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

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

Проверка результата после обновления

Факт завершения обновления в конфигураторе ещё не гарантирует, что база работает корректно. Минимальная проверка занимает несколько минут и включает контроль версии, работоспособности изменённых механизмов и отсутствие ошибок в журнале регистрации.

Контрольные точки

Как проверить результат

Версия конфигурации в разделе «О программе»

Норма

Отображается новая версия

Тревожный признак

Старая версия — обновление не применилось или пользователь не перезашёл

Работа изменённой функции

Норма

Новое поведение соответствует задуманному

Тревожный признак

Ошибки выполнения, старое поведение у перезашедших пользователей

Журнал регистрации

Норма

Нет массовых ошибок после момента обновления

Тревожный признак

Ошибки «Ошибка формата потока», «Конфликт блокировок» у многих сеансов

Фоновые и регламентные задания

Норма

Выполняются без ошибок

Тревожный признак

Задания падают — возможно, изменён код, который они используют

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

Типичные ошибки и ограничения

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

Ещё одно ограничение: динамическое обновление не отменяет необходимости периодических монопольных операций. Тестирование и исправление, очистка устаревших данных, обновление релизов — всё это по-прежнему требует окна обслуживания без пользователей.

Маршрут решения

Как выбрать действие

Изменены только модули, формы, макеты, ролиВыполните динамическое обновление, затем перезапустите сеансы

Конфигуратор показывает список таблиц для реструктуризацииЗапланируйте монопольное обновление в нерабочее время

Исправление критично и влияет на расчётыДаже при динамическом обновлении принудительно завершите все сеансы

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

FAQ

Можно ли динамически обновить типовую конфигурацию на новый релиз?

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

Что увидят пользователи во время динамического обновления?

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

Опасно ли динамическое обновление для данных?

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

Как принудительно завершить сеансы после динамического обновления?

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

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

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

Почему конфигуратор не предлагает динамическое обновление?

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