При работе с распределенными информационными базами (РИБ) одной из самых неприятных проблем является сбой при вызове метода ПрочитатьИзменения. Текст ошибки гласит: «Данные принимаются от узла с другим набором расширений, меняющих структуру данных. Необходимо произвести перенос расширений конфигурации в узел». Ситуация осложняется тем, что часто визуально список расширений в центральной и периферийной базах кажется идентичным, а иногда пользователь и вовсе уверен, что расширения не используются. В этой статье мы подробно разберем, почему возникает эта коллизия и как привести узлы к «общему знаменателю».
Выясняем причину: почему РИБ блокирует обмен
Проанализируем механику работы 1С в данном контексте. При обмене данными система сравнивает не только версии основной конфигурации, но и состояние расширений. Критически важным является свойство расширения «Используется для изменения структуры данных». Если в расширении добавлены новые реквизиты, справочники или документы, 1С вычисляет хэш-сумму всей структуры метаданных. Если хэш в файле обмена не совпадает с хэшем принимающей базы, выполнение метода ПрочитатьИзменения прерывается из соображений безопасности, чтобы не допустить повреждения данных.
Рассмотрим основные причины расхождения:
Разные версии платформы 1С:Предприятие. Это наиболее частая причина, скрытая от глаз. Разные релизы платформы могут по-разному формировать хэш-сумму структуры данных.
Автоматические патчи (исправления). Современные конфигурации (на базе БСП) умеют самостоятельно скачивать и устанавливать исправления. Технически патч — это расширение. Если центр скачал патч, а периферия нет, обмен «встанет».
Некорректный способ обновления расширений. Использование механизма «Сравнить и объединить» для расширений в РИБ часто приводит к тому, что внутренние идентификаторы объектов (UUID) начинают различаться.
Фантомные записи в системных таблицах. Иногда после удаления расширения сведения о нем остаются в служебной таблице Config.
Решение 1: Синхронизация версий платформ
Прежде чем приступать к манипуляциям с конфигурацией, проверим технические параметры среды. Опыт показывает, что если центральный узел работает, например, на платформе версии 8.3.11, а периферийный — на 8.3.10, система может выдать ошибку о расширениях, даже если их нет. Разберем шаги по устранению этой причины:
Выясним точный номер версии платформы в центральной базе (Меню — Справка — О программе).
Убедимся, что на всех периферийных узлах установлена точно такая же версия.
Обновим платформу на тех узлах, где она отличается. В большинстве случаев после приведения систем к единому релизу ошибка исчезает без дополнительных действий.
Решение 2: Проверка и перенос расширений-патчей
Если платформы идентичны, но ошибка сохраняется, посмотрим на наличие скрытых расширений. Проанализируем ситуацию с патчами. В современных конфигурациях перейдем в раздел Администрирование — Обслуживание — Обновление программы — Установленные исправления (патчи). Если список в центре и на периферии отличается, необходимо сделать следующее:
В центральном узле выгрузим все установленные патчи в файлы .cfe.
В периферийном узле загрузим эти файлы. Важно: загрузку следует выполнять не через механизм сравнения, а через полную замену или автоматическую установку, чтобы сохранить идентичность метаданных.
Если патчи не критичны, можно попробовать удалить их во всех узлах, совершить обмен, а затем позволить системе скачать их заново синхронно.
Решение 3: Ручная синхронизация через выгрузку конфигурации (cf)
Рассмотрим метод, который помогает, когда стандартные средства пасуют. Попробуем «протолкнуть» структуру данных принудительно. Выполним следующие действия:
В центральной базе внесем любое несущественное изменение в основную конфигурацию (например, добавим неиспользуемую константу).
Выполним обновление конфигурации базы данных (F7).
Выгрузим файл конфигурации (Конфигурация — Сохранить конфигурацию в файл...).
В периферийной базе загрузим этот файл через Конфигурация — Загрузить конфигурацию из файла (именно загрузить, а не объединить).
После этого попробуем запустить обмен. Это обновит ожидаемую структуру метаданных в подчиненном узле.
Решение 4: Программный сброс привязки узла
Выясним, как поступить в самом тяжелом случае, когда база «заклинило». Мы можем временно разорвать связь РИБ, чтобы почистить расширения в автономном режиме. Для этого воспользуемся встроенным языком 1С.
Разберем последовательность действий:
В периферийной базе создадим внешнюю обработку и выполним код:
// Разрываем связь с главным узлом
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Теперь база считается автономной. Удалим из нее все расширения, которые могут вызывать подозрение.
Удалим все файлы обмена (сообщения) в каталоге обмена, чтобы начать цикл синхронизации с чистого листа.
Снова установим связь с центром. Для этого в той же обработке выполним:
// СсылкаНаУзел — это ссылка на элемент плана обмена, соответствующий центральной базе
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентральныйУзел);
Запустим обмен. При первом сеансе система может передать большой объем данных, это нормально.
Важные рекомендации по работе с расширениями в РИБ
Чтобы избежать повторения ситуации в будущем, проанализируем правила «хорошего тона» при разработке в распределенной среде:
Метод загрузки: Всегда загружайте расширения в подчиненные узлы только через «Загрузить конфигурацию расширения» из файла .cfe, полученного из центра. Никогда не создавайте расширение в периферии вручную с тем же именем — у них будут разные внутренние идентификаторы (UUID).
Тестирование и исправление: При возникновении «фантомных» ошибок запустите штатное «Тестирование и исправление» с включенными опциями «Проверка логической целостности» и «Очистка ссылок на несуществующие объекты».
Очистка кэша: Иногда ошибка является следствием некорректного кэширования метаданных платформой. Попробуйте очистить кэш на стороне сервера 1С и на локальном компьютере пользователя.
Подводя итог, отметим: ошибка ПрочитатьИзменения из-за расширений чаще всего лечится либо обновлением платформ до идентичного релиза, либо строгим соблюдением последовательности переноса .cfe файлов. Мы надеемся, что предложенные шаги помогли вам восстановить стабильную работу обмена данными.