Работа с расширениями в распределенных информационных базах (РИБ) — это мощный инструмент, который, однако, таит в себе множество подводных камней. Одной из наиболее частых и неприятных проблем является внезапная остановка обмена данными после того, как в расширение были добавлены новые реквизиты или объекты метаданных. В этой статье мы подробно разберем, почему платформа 1С блокирует синхронизацию даже для тех расширений, которые не используются на периферийных узлах, и как правильно выходить из этой ситуации.
Рассмотрим стандартную ситуацию: у вас есть основная база и несколько подчиненных узлов. Вы создаете расширение, которое добавляет новые реквизиты в справочники или создает новые документы. Вы полагаете, что если в свойствах расширения снять флаг Используется в распределенной информационной базе, то эти изменения останутся только в центральном узле и не повлияют на обмен. Однако на практике синхронизация останавливается с ошибкой.
Выясним причину такого поведения платформы. Когда расширение добавляет реквизиты или новые объекты, оно физически меняет структуру таблиц в базе данных (SQL или файловой). Платформа 1С строго следит за целостностью схемы данных всей системы. Для этого используется механизм контрольных сумм (Checksum) структуры метаданных. При попытке обмена узлы сравнивают свои конфигурации. Если на главном узле структура таблиц изменилась из-за расширения, а на подчиненном — нет, возникает конфликт. Платформа блокирует обмен, чтобы предотвратить потенциальную порчу данных, так как она не может гарантировать корректность записи информации в таблицы с разной структурой.
Проанализируем основные сообщения об ошибках, с которыми сталкиваются разработчики:
Рассмотрим по шагам, как нужно действовать, если вам необходимо добавить метаданные через расширение в распределенной базе.
Если ваше расширение добавляет хотя бы один реквизит в существующий объект или создает новый справочник/документ, флаг Используется в распределенной информационной базе должен быть включен обязательно. Это единственный способ гарантировать, что структура таблиц на всех узлах будет идентичной. Даже если логика этого расширения (код в модулях) не нужна на периферии, описание структуры данных обязано там присутствовать.
После того как изменения из центрального узла попали в подчиненный через файл обмена, обновление в режиме Конфигуратор может потребовать дополнительных действий. Проанализируем ситуацию: иногда после загрузки сообщения обмена база просит обновить конфигурацию, но при запуске возникают ошибки отсутствия расширений.
В этом случае рекомендуем выполнить следующие действия:
Конфигуратор подчиненного узла./C ОбновитьКонфигурациюИБ.Если вы решили полностью удалить расширение, которое уже успело "наследить" в структуре данных, вам потребуется очистить таблицы регистрации изменений. Рассмотрим пример, когда расширение удалено, но обмен все равно требует его наличия. Это происходит из-за того, что в плане обмена остались записи, ссылающиеся на объекты этого расширения.
Воспользуйтесь стандартной обработкой Регистрация изменений для обмена. Найдите объекты метаданных, которые были затронуты удаленным расширением, и принудительно удалите все регистрации изменений по ним для проблемного узла.
Разберем важный нюанс: современные версии платформы стали гораздо жестче контролировать состав расширений. Если раньше многие ошибки прощались, то теперь контроль за ConfigCAS (внутренняя таблица для хранения версий расширений) стал приоритетным.
Посмотрим на пример из практики: вы добавили справочник в расширение WEB, которое нужно только на сервере. Обмены "потухли". Вы пытаетесь обновить узлы, но они жалуются на отсутствие WEB. Это происходит потому, что 1С не проверяет, используется ли этот справочник в обмене — она видит общее изменение структуры всей базы данных. Единственный надежный способ — позволить расширению мигрировать во все узлы РИБ.
Чтобы избежать многочасовых ручных обновлений и разборов Журнала Регистрации, придерживайтесь следующих правил:
Резюме: Главная ошибка заключается в попытке локального изменения структуры данных в распределенной системе. Помните: любая новая колонка в таблице — это изменение, которое касается каждого узла вашей сети. Соблюдение единообразия структуры через включение расширений в состав РИБ избавит вас от большинства ошибок синхронизации.