Как запретить динамическое обновление конфигурации 1С

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

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

Ниже разобраны все рабочие способы запрета: настройка кластера сервера 1С, запрет на уровне конфигурации, контроль прав пользователей и проверка того, что запрет действительно сработал.

Чем опасно динамическое обновление и когда его запрещают

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

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

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

Запрет через свойства базы на сервере 1С

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

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

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

1. 1
   Откройте консоль администрирования серверов 1С и найдите нужную базу
2. 2
   Откройте свойства базы через контекстное меню
3. 3
   Установите запрет динамического обновления конфигурации БД и сохраните
4. 4
   Проверьте: попробуйте выполнить динамическое обновление из конфигуратора — оно должно быть отклонено
5. 5
   Задокументируйте изменение, чтобы другие администраторы не вернули настройку обратно

Контроль через утилиту rac

Если у вас нет доступа к графической консоли (например, сервер на Linux), тот же параметр меняется через утилиту командной строки rac: получите список баз, запросите свойства нужной базы командой rac infobase info, затем обновите параметр командой rac infobase update с указанием соответствующего ключа. Точное имя параметра смотрите в справке утилиты вашей версии платформы — оно может отличаться между релизами.

Запрет на уровне конфигурации и прав доступа

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

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

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

Организационные меры: регламент обновлений

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

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

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

Сравнение вариантов запрета

Настройка кластера сервера

Самый надёжный способ, блокирует обновление на уровне платформы. Работает только в клиент-серверном режиме.

Ограничение прав пользователей

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

Регламент и журнал обновлений

Не блокирует технически, но снижает риск ошибок и упрощает расследование инцидентов.

Проверка результата и типичные ошибки

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

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

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

Частые вопросы

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

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

Что произойдёт, если база уже динамически обновлена, а потом включить запрет?

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

Мешает ли запрет обновлению через расширения конфигурации?

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

Почему после запрета обновление всё равно проходит?

Чаще всего изменён не тот объект (например, настройку применили к другой базе кластера), параметр не сохранён, или обновление выполняет учётная запись с правами администратора кластера, которая обходит ограничение. Проверьте настройки конкретной базы и состав учётных записей администраторов.

Нужно ли перезапускать сервер 1С после изменения настройки?

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