Администрирование · 12 мин
Динамическое обновление в 1С: что это и как применять без риска
Что такое динамическое обновление конфигурации в 1С, как оно работает, когда его можно применять без отключения пользователей и в каких случаях оно опасно.
Динамическое обновление в 1С — это режим обновления конфигурации базы данных, при котором изменения применяются без завершения работы пользователей и без монопольного доступа к информационной базе. Вместо полной остановки сеансов платформа подгружает новую версию конфигурации «на лету»: работающие пользователи продолжают работать на старой версии, а изменения подхватываются при перезапуске их сеансов.
Механизм появился для решения практической задачи: в крупных базах, где одновременно работают десятки и сотни сотрудников, каждое обновление с выгоном пользователей означает остановку бизнес-процессов. Динамическое обновление позволяет накатывать мелкие исправления и доработки в рабочее время, не прерывая учёт.
Однако у режима есть жёсткие ограничения. Он применим только тогда, когда изменения не затрагивают структуру базы данных в части, требующей реструктуризации таблиц. Попытка обновить конфигурацию динамически при наличии таких изменений либо завершится ошибкой, либо — что хуже — приведёт к расхождению версий конфигурации у разных пользователей и ошибкам в данных. Ниже разберём, как работает механизм, когда его можно использовать и как проверить результат.
Как работает механизм динамического обновления
При обычном обновлении конфигурации базы данных платформа требует монопольного доступа: все сеансы завершаются, выполняется реструктуризация таблиц, и только после этого пользователи заходят в базу уже на новой версии. При динамическом обновлении платформа поступает иначе: она сохраняет новую версию конфигурации базы данных, но активные сеансы продолжают работать на версии, загруженной при их старте.
Технически это реализовано через кэш метаданных. Каждый сеанс при запуске считывает конфигурацию и работает с ней. После динамического обновления новые сеансы получают уже обновлённую конфигурацию, а старые — доигрывают на прежней. Поэтому в один момент времени в базе могут одновременно работать пользователи на разных версиях конфигурации. Это нормально для краткого переходного периода, но опасно, если затягивается.
Для запуска динамического обновления в конфигураторе используется команда «Конфигурация → Обновить конфигурацию базы данных» с установленным флагом «Динамическое обновление», либо пакетный режим с соответствующим параметром командной строки. Платформа сама анализирует список изменений и предупреждает, если для их применения требуется монопольный режим.
Какие изменения можно применять динамически
Главный критерий — затрагивает ли изменение структуру таблиц базы данных. Если нет, динамическое обновление, как правило, возможно. К безопасной категории относятся правки программного кода и пользовательского интерфейса.
- изменение модулей: общих, модулей объектов, форм, команд;
- правка форм: расположение элементов, обработчики событий, условное оформление;
- изменение макетов печатных форм и отчётов;
- добавление новых объектов метаданных, которые ещё не используются в работающих сеансах;
- правка ролей и прав доступа в части, не меняющей структуру хранения;
- изменение запросов, алгоритмов, бизнес-логики без изменения состава реквизитов.
Типичный сценарий корректного применения — срочное исправление ошибки в модуле проведения документа или в печатной форме в середине рабочего дня. Администратор обновляет конфигурацию динамически, пользователи перезаходят в базу при удобном моменте и получают исправленную версию.
Когда динамическое обновление применять нельзя
Если изменения требуют реструктуризации — физического изменения таблиц базы данных — динамическое обновление либо невозможно технически, либо крайне нежелательно. Платформа в ряде случаев блокирует такую попытку, но не во всех сценариях, поэтому полагаться только на автоматическую проверку нельзя.
- добавление, удаление или переименование реквизитов объектов;
- изменение типа или длины существующего реквизита;
- добавление измерений, ресурсов, реквизитов в регистры;
- изменение состава табличных частей;
- добавление объектов в состав планов обмена с действующими узлами;
- изменение режимов: например, включение разделения данных или изменение иерархии справочника.
Отдельная опасная ситуация — когда динамически обновили код, который пишет данные, а структура осталась прежней, но логика записи изменилась. Тогда часть пользователей на старой версии записывает данные по одним правилам, а часть на новой — по другим. Результат: рассинхронизация учётных данных, которую сложно выявить и исправить.
Порядок выполнения динамического обновления
Безопасный сценарий начинается не с конфигуратора, а с резервной копии. Даже «безобидное» динамическое обновление может пойти не так, и откат без копии будет затруднён. Далее действия выполняются в конфигураторе.
После применения обновления обязательно сообщите пользователям о необходимости перезайти в базу. Пока сеанс не перезапущен, пользователь работает на старой версии. В клиент-серверном режиме администратор может отслеживать активные сеансы через консоль кластера и контролировать, кто ещё не обновился.
- 1Сделайте резервную копию базы (выгрузку в dt или средствами СУБД)
- 2Откройте конфигуратор и загрузите изменения в конфигурацию базы данных
- 3Выполните команду «Конфигурация → Обновить конфигурацию базы данных»
- 4Проверьте список изменений: если платформа требует монопольный режим — отмените и планируйте обычное обновление
- 5Установите флаг «Динамическое обновление» и подтвердите применение
- 6Дождитесь сообщения об успешном завершении
- 7Уведомьте пользователей о необходимости перезайти в базу
- 8Проверьте работу изменённого функционала на тестовом сценарии
Как проверить результат и контролировать сеансы
Факт успешного применения динамического обновления подтверждается сообщением конфигуратора, но это не гарантирует, что все пользователи уже работают на новой версии. Контроль нужно вести по сеансам.
В клиент-серверном варианте откройте консоль кластера серверов 1С и посмотрите список активных сеансов по времени их начала: сеансы, запущенные до обновления, работают на старой конфигурации. В файловом варианте ориентируйтесь на список активных пользователей в конфигураторе (Администрирование → Активные пользователи) — там также видно время начала сеанса.
Функциональную проверку выполняйте на том объекте, который менялся: откройте изменённую форму, проведите тестовый документ, сформируйте изменённый отчёт. Если после обновления у пользователей появляются ошибки вида «Ошибка формата потока» или «Конфигурация базы данных была изменена», это признак того, что сеанс работает на устаревшей версии и его нужно перезапустить.
Как проверить результат
Обновление завершено без ошибок и предупреждений о монопольном режиме
Платформа требовала монопольный доступ или выдала ошибку реструктуризации
Все активные сеансы начаты позже момента обновления
Есть сеансы, запущенные до обновления — они на старой версии
Форма, отчёт или документ работают по новой логике
Ошибки выполнения, старое поведение, «Ошибка формата потока»
Типичные ошибки и их последствия
Большинство проблем с динамическим обновлением возникает не из-за самого механизма, а из-за нарушения дисциплины его применения. Ниже — ситуации, которые встречаются чаще всего.
Ещё одна распространённая ошибка — серия из нескольких динамических обновлений подряд в течение дня. Каждое из них увеличивает «разброс» версий среди пользователей, усложняет диагностику ошибок и повышает нагрузку на сервер. Если правок много, правильнее накопить их и применить одним обычным обновлением в нерабочее время.
Динамическое или обычное обновление: как выбрать
Выбор режима определяется характером изменений и критичностью непрерывной работы. Динамическое обновление — инструмент для точечных правок кода и интерфейса в рабочее время. Обычное обновление с монопольным доступом — стандарт для всего остального: релизов поставщика, изменений структуры данных, масштабных доработок.
Практическое правило: если сомневаетесь, требует ли изменение реструктуризации, считайте, что требует. Проверить можно заранее на копии базы: конфигуратор при обновлении покажет список изменений и потребует монопольный режим, если он нужен. Тестирование на копии — обязательный этап перед любым обновлением рабочей базы, независимо от режима.
Сравнение вариантов
Подходит для правок кода, форм, макетов в рабочее время. Ограничение: нельзя при изменении структуры таблиц, пользователи временно работают на разных версиях
Подходит для любых изменений, включая реструктуризацию и обновление релизов. Ограничение: требует завершения всех сеансов и остановки работы
Подходит для сложных доработок и нестандартных конфигураций. Ограничение: занимает больше времени, требует дополнительного контура
Как выбрать действие
Часто задаваемые вопросы
Можно ли откатить динамическое обновление?
Прямой кнопки «откатить» нет. Возврат выполняется восстановлением конфигурации из резервной копии: либо загрузкой сохранённого файла конфигурации (cf), либо полным восстановлением базы из dt или копии СУБД. Именно поэтому копия перед любым обновлением обязательна, даже если правка кажется незначительной.
Что произойдёт, если пользователь не перезайдёт в базу после динамического обновления?
Он продолжит работать на версии конфигурации, загруженной при старте его сеанса. Если изменения касались только интерфейса — последствий почти не будет. Если менялась логика записи данных — пользователь будет создавать данные по старым правилам, что приведёт к расхождениям в учёте. Сеансы, запущенные до обновления, нужно завершать в разумный срок.
Почему после динамического обновления у пользователей появляется «Ошибка формата потока»?
Чаще всего причина в рассогласовании кэша метаданных: клиентский сеанс работает со старой версией, а сервер уже отдаёт новую. Стандартное решение — завершить проблемный сеанс и запустить его заново. Если ошибка повторяется массово, помогает очистка кэша на клиентских машинах или перезапуск сервера 1С.
Можно ли выполнять динамическое обновление в файловой базе?
Да, механизм работает и в файловом варианте. Разница в контроле: в файловой базе нет консоли кластера, поэтому активные сеансы отслеживаются через список активных пользователей в конфигураторе. Ограничения по типам изменений те же, что и в клиент-серверном режиме.
Подходит ли динамическое обновление для установки нового релиза типовой конфигурации?
Как правило, нет. Релизы поставщика почти всегда содержат изменения структуры данных и требуют реструктуризации, а также выполнения обработчиков обновления, рассчитанных на монопольный режим. Типовые релизы обновляйте стандартно, с завершением сеансов и обязательной резервной копией.
Как понять заранее, потребует ли обновление реструктуризации?
Надёжный способ — выполнить обновление на копии базы: конфигуратор покажет окно со списком изменений, и если среди них есть изменения структуры таблиц, платформа запросит монопольный режим. Косвенный признак — наличие в списке изменений реквизитов, измерений, ресурсов или табличных частей.
Что важно запомнить
Динамическое обновление — инструмент для точечных правок кода и интерфейса без остановки работы пользователей. Оно недопустимо при изменениях структуры данных и опасно при правках логики записи. Перед применением делайте резервную копию, после — контролируйте перезапуск сеансов и проверяйте изменённый функционал.