← На главную

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

Суть проблемы: нединамичное обновление модулей менеджера

Основная сложность, с которой мы столкнулись, заключается в следующем: после перехода с платформы 8.3.17 на 8.3.20.1613 (и, как показывают дальнейшие наблюдения, на более поздние версии, такие как 8.3.18.1334 и 8.3.27.1936) любое изменение в модуле менеджера объекта конфигурации приводит к невозможности динамического обновления. Вместо этого система настойчиво требует установить монопольный режим, что влечет за собой необходимость завершения работы всех пользователей.

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

1. Зависимость от режима совместимости: Мы заметили, что проблема проявляется исключительно на базах, работающих без режима совместимости (то есть, когда режим совместимости установлен в значение «Не используется»). Информационные базы, где установлен режим совместимости (например, с версиями 8.2.13, 8.2.16 или 8.3.8), продолжают обновляться динамически при изменении модулей менеджера. Это является критически важным наблюдением, указывающим на связь проблемы с новыми механизмами платформы, активирующимися при отключении режима совместимости.
2. Специфика модулей: Требование монопольного режима возникает только при изменении модулей менеджера объектов конфигурации (например, СправочникМенеджер, ДокументМенеджер и т.д.). Изменения в модулях объекта (СправочникОбъект, ДокументОбъект), модулях форм или общих модулях по-прежнему позволяют выполнять динамическое обновление.
3. Противоречивые наблюдения по повторяемости: Здесь мнения пользователей разделились, что указывает на сложный и, возможно, многофакторный характер проблемы:
   • Некоторые утверждают, что монопольный режим требуется после первого изменения каждого модуля менеджера объекта конфигурации без режима совместимости. Дальнейшие изменения в том же модуле к такому эффекту не приводят. Это наводит на мысль об однократной конвертации или инициализации внутренних структур.
   • Другие, напротив, сообщают, что требование монопольного режима возникает каждый раз после изменения модуля менеджера любого объекта, даже при добавлении простого пробела. Это противоречит гипотезе об однократной конвертации и указывает на более глубокую и постоянную причину.
4. Проявление на расширениях: Похожая проблема была зафиксирована и при обновлении расширений, что расширяет круг затронутых компонентов и свидетельствует о системном характере изменения поведения платформы.
5. Общая необъяснимость: Несмотря на актуальность проблемы, она остается малоосвещенной в официальной документации 1С, и поиск в открытых источниках дает немного конкретных ответов. Это создает дополнительные трудности в понимании и решении.

Анализ проблемы, гипотезы и возможные обходные пути

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

Внутренняя конвертация структуры метаданных

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

Рассмотрим подробнее, почему это может происходить:

1. Новые механизмы платформы: Версии платформы, начиная с 8.3.20, вводят ряд новых возможностей и внутренних механизмов. Когда мы отключаем режим совместимости, платформа начинает использовать все свои актуальные функции. Возможно, эти новые механизмы требуют и новой структуры хранения метаданных, или же изменения в модуле менеджера инициируют перекомпиляцию или переиндексацию, которая затрагивает внутренние системные таблицы, требующие эксклюзивного доступа.
2. Однократность конвертации: Если конвертация действительно происходит, то логично предположить, что она единоразова для каждого объекта или всей конфигурации при первом изменении модуля менеджера после перехода на новую версию без режима совместимости. Это объяснило бы наблюдения тех пользователей, у кого монопольный режим требуется только при первом изменении. Однако, если конвертация действительно происходит каждый раз, это указывает на более сложную ситуацию, возможно, связанную с кэшированием или особенностями работы клиент-серверного режима.
3. Влияние на структуру данных: Динамическое обновление предназначено для изменений, не затрагивающих структуру данных. Если изменение в модуле менеджера, даже кажущееся безобидным (например, добавление пробела), запускает внутренний процесс, который платформа интерпретирует как изменение структуры метаданных, то требование монопольного режима становится оправданным с точки зрения целостности данных.

Роль режима совместимости

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

1. Ограничение новых возможностей: Когда мы устанавливаем режим совместимости (например, Версия 8.3.8), платформа 1С имитирует поведение более старой версии. Это означает, что многие новые механизмы и внутренние оптимизации, введенные в 8.3.20 и выше, остаются неактивными. Именно поэтому базы с включенным режимом совместимости не демонстрируют описанную проблему: старые механизмы работы с модулями менеджера и метаданными продолжают использоваться.
2. Активация новых функций без совместимости: Переключение режима совместимости в значение Не используется полностью активирует все актуальные возможности текущей версии платформы. Это, с одной стороны, позволяет использовать весь потенциал платформы, но с другой — может вызывать непредвиденные побочные эффекты, если конфигурация не была полностью адаптирована к этим изменениям или если сама платформа имеет недокументированные особенности поведения. Мы видим, что именно в этом режиме проблема и проявляется.
3. Изменение структуры объектов: Важно понимать, что отключение режима совместимости может приводить к изменению структуры некоторых объектов базы данных, даже если на первый взгляд это не очевидно. Такие изменения требуют перестроения индексов, таблиц или других внутренних представлений данных, что естественным образом требует монопольного доступа.

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

Динамическое обновление — это мощный, но ограниченный механизм. Мы знаем, что:

1. Когда динамическое обновление работает: Оно предназначено для изменений, не затрагивающих структуру хранения данных: код модулей (за исключением случаев, когда код влияет на метаданные), формы, макеты, роли, параметры отчетов и т.д.
2. Когда требуется монопольный режим: Монопольный режим всегда необходим для операций, которые изменяют физическую структуру базы данных (добавление/удаление реквизитов, таблиц, объектов конфигурации) или требуют эксклюзивного доступа к метаданным для их реструктуризации или конвертации. Проблема, которую мы обсуждаем, подводит нас к мысли, что изменение модуля менеджера в определенных условиях (новая платформа, нет режима совместимости) попадает в эту категорию, даже если это не заявлено явно.
3. Проблемы с кэшем метаданных: Иногда проблемы с динамическим обновлением могут быть вызваны некорректным кэшированием метаданных на клиенте или сервере. Однако, в данном случае, систематическое проявление проблемы именно для модулей менеджера и зависимость от режима совместимости указывают на более глубокие причины, нежели просто ошибки кэширования.

Обновление расширений

Проблема, затронувшая расширения, также важна. Исторически, обновление расширений могло требовать монопольного режима, если изменения затрагивали внутренние структуры. Например, в более поздних версиях платформы (8.3.22) появились специальные механизмы, позволяющие изменять параметры номеров и кодов объектов в расширениях без перевода конфигурации в монопольный режим. Это свидетельствует о том, что ранее подобные изменения (или изменения, влияющие на аналогичные внутренние механизмы) требовали монопольного доступа. Таким образом, наблюдаемое поведение с расширениями вполне укладывается в общую картину изменения требований платформы к монопольному режиму при работе с метаданными.

Возможные подходы и временные решения

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

1. Принятие монопольного режима для "первого" изменения

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

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

2. Временное возвращение к режиму совместимости

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

   Чтобы изменить режим совместимости, выполните следующие шаги:

   1. Запустите конфигуратор в монопольном режиме.
   2. Перейдите в меню Конфигурация - Свойства конфигурации.
   3. На вкладке Основные найдите поле Режим совместимости.
   4. Выберите требуемую версию (например, Версия 8.3.8).
   5. Сохраните конфигурацию (Файл - Сохранить конфигурацию) и обновите конфигурацию базы данных (Конфигурация - Обновить конфигурацию базы данных).

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

3. Перенос кода в расширения или общие модули

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

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

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

   Допустим, у нас есть функция в модуле менеджера справочника:

   Скопировать код

   
   // Модуль менеджера справочника "МойСправочник"
   Функция ПолучитьНазваниеПоКоду(КодСправочника) Экспорт
       Возврат ЭтотОбъект.НайтиПоКоду(КодСправочника).Наименование;
   КонецФункции
   

   Если эту функцию можно было бы перенести в общий модуль без потери функциональности, мы могли бы это сделать:

   Скопировать код

   
   // Общий модуль "МоиПолезныеФункции"
   Функция ПолучитьНазваниеСправочникаПоКоду(КодСправочника) Экспорт
       Возврат Справочники.МойСправочник.НайтиПоКоду(КодСправочника).Наименование;
   КонецФункции
   

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

4. Тщательное тестирование и документирование

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

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

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