Почему вылетает 1С в узлах РИБ при использовании расширений с данными и как это исправить

← На главную

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

Анализ причины: особенности платформы 8.3.16 и механизм XDTO

Проанализируем ситуацию, возникшую в версии платформы 8.3.16. Основная проблема заключается в том, как 1С обрабатывает сериализацию данных при обмене. Когда мы добавляем реквизит в расширение, структура базы данных физически меняется: создаются дополнительные таблицы или поля. При обмене данными через РИБ используется механизм XDTO-сериализации.

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

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

Решение 1: Обновление технологической платформы

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

Проанализируем текущую версию. Если вы используете 8.3.16, рекомендуется переход на версию не ниже 8.3.18.1201 или актуальные релизы веток 8.3.20 и выше.
В новых версиях исправлены механизмы фонового обновления конфигурации базы данных в узлах РИБ, если расширение содержит данные.
После обновления платформы на всех узлах (и сервере, и клиентах), попробуйте повторно применить расширение.

Решение 2: Перенос реквизитов в основную конфигурацию

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

Выполним следующие действия для стабилизации системы:

Снимем основную конфигурацию с поддержки (с возможностью редактирования).
Перенесем добавленные реквизиты из расширения непосредственно в объекты основной конфигурации (например, в документ ЗаказПокупателя).
В расширении оставим только программную логику и модификацию форм. Сами данные теперь будут принадлежать основной конфигурации.
Удалим "проблемное" расширение из всех узлов и выполним типовой обмен РИБ для синхронизации структуры основной конфигурации.

Преимущество этого метода: механизмы РИБ гарантированно умеют работать с реквизитами основной конфигурации. Это исключает ошибки десериализации и гарантирует регистрацию изменений в планах обмена.

Решение 3: Использование дополнительных реквизитов (БСП)

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

Рассмотрим алгоритм реализации:

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

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


// Пример получения значения дополнительного реквизита
ЗначениеРеквизита = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаОбъект, "МойДополнительныйРеквизит");

Решение 4: Ручное управление расширениями на узлах

Если вам критически важно использовать именно расширение с данными, проанализируем порядок его внедрения в РИБ. Автоматическая передача расширения через флаг Использовать в РИБ часто дает сбои.

Попробуем применить "ручной" метод синхронизации:

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

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