← На главную

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

Техническая возможность: когда динамическое обновление допустимо?

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

Посмотрим, какие изменения можно вносить динамически, а какие категорически нельзя.

Изменения, для которых возможно динамическое обновление:

1. Изменение кода в модулях (например, Модуль объекта, Модуль менеджера, Модуль формы, общие модули).
2. Редактирование форм: изменение расположения элементов, добавление новых элементов, не связанных с данными, изменение их свойств.
3. Добавление и изменение макетов (печатных форм, шаблонов).
4. Добавление и изменение ролей и прав доступа.
5. Создание и настройка общих команд, интерфейсов.
6. Добавление новых отчетов и обработок, у которых нет реквизитов, требующих хранения в базе данных (т.е. нет реструктуризации таблиц).

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

1. Добавление или удаление любых объектов метаданных, создающих таблицы в БД (справочники, документы, регистры накопления, сведений, расчета и т.д.).
2. Добавление, удаление или изменение реквизитов, измерений, ресурсов у существующих объектов.
3. Изменение типа данных существующего реквизита (например, со Строка на Число).
4. Изменение свойств реквизитов, влияющих на структуру поля в СУБД (например, изменение длины строки или точности числа).
5. Изменение состава или типа планов видов характеристик, планов счетов, планов видов расчета.

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

Почему динамическое обновление называют «демоническим»: главные риски

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

1. Рассинхронизация сеансов и кэша

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

• Новые сеансы пользователей запускаются уже с новой версией конфигурации.
• Старые (активные) сеансы продолжают работать со старой версией конфигурации, которая закэширована у них на клиенте и на сервере.

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

2. Повреждение структуры конфигурации в базе данных

Это редкий, но самый катастрофический сценарий. В процессе динамического обновления может произойти сбой (проблемы с сетью, сбой сервера 1С, ошибка в СУБД). Такой сбой может повредить служебные таблицы, в которых сама 1С хранит конфигурацию (в частности, таблицу Config). Последствия фатальны: база перестает открываться как в режиме Предприятия, так и в Конфигураторе, выдавая ошибку "Нарушена целостность структуры конфигурации". Восстановление после такой ошибки — нетривиальная задача, часто требующая вмешательства опытного администратора СУБД и выполнения низкоуровневых запросов к базе данных.

3. Потеря изменений

Существует риск, что после серии динамических обновлений, при последующем "большом" обновлении в монопольном режиме, некоторые динамически внесенные изменения могут быть "затерты". Это происходит из-за рассинхронизации между основной конфигурацией (в Конфигураторе) и конфигурацией базы данных. Платформа может решить, что конфигурация БД отличается от основной, и "привести ее в соответствие", откатив ваши "горячие" исправления.

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

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

1. Обязательное тестирование на копии

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

2. Плановые обновления в монопольном режиме — лучший выбор

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

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

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

3. Используйте расширения для срочных исправлений

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

4. Оценка рисков

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

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