Ситуация, когда конфигурации в центральном и периферийном узлах распределенной информационной базы (РИБ) кажутся идентичными, но ведут себя по-разному, — это классическая проблема «фантомных» метаданных. Мы можем столкнуться с тем, что в одной базе реквизит виден и доступен, а в другой он отсутствует даже в Конфигураторе, несмотря на загрузку идентичного файла .cf. Разберем по шагам, почему это происходит и как привести систему в чувство.
Прежде всего, выясним причину. В 1С:Предприятие структура метаданных хранится в нескольких местах одновременно. Основная конфигурация находится в таблице Config, а физическая структура таблиц базы данных (на уровне SQL или файловой системы) — в DBSchema. Кроме того, существуют многочисленные уровни кэширования: на стороне клиента, на стороне сервера приложений и даже внутри самой базы данных в виде записей о динамических обновлениях.
Рассмотрим основной механизм сбоя: чаще всего это результат неудачного «динамического обновления» (обновления в режиме «Демон»). При таком обновлении система создает новую версию объекта, но если в момент фиксации произошел сбой или в базе находились пользователи, старая версия метаданных может «застрять» в кэше или в таблице структуры БД. В итоге мы получаем ситуацию, когда Конфигуратор показывает одно, а режим Предприятия или механизм обмена — совсем другое.
Начнем с самого простого, но обязательного действия. Обычной очистки кэша в папке пользователя AppData часто недостаточно. Проанализируем ситуацию шире:
1C:Enterprise Server Admin и очистить содержимое папки snccntx, которая находится внутри каталога srvinfo. Там хранятся сеансовые данные, которые могут удерживать старые описания метаданных./ClearConfigCache. Это заставит платформу игнорировать локальные копии и перечитать структуру метаданных напрямую из базы данных.Если «визуально» конфигурации одинаковы, проверим их инструментально. Разберем, как выполнить сравнение максимально эффективно:
.cf.Важный момент: если вы используете платформу 8.3 даже для старых конфигураций (например, УПП 1.3 или БП 2.0), проверьте наличие «Расширений конфигурации». В периферийной базе может быть подключено расширение, которое добавляет реквизит «поверх» основной конфигурации. В этом случае в основном .cf его не будет, но в Предприятии он появится.
Автор темы столкнулся с тем, что «ошибка преобразования XML» мешает обмену. Это происходит потому, что периферийная база пытается выгрузить данные реквизита, которого (с точки зрения центральной базы) не существует. XML-схема сообщения обмена формируется на основе метаданных отправителя.
Чтобы вылечить обмен, мы можем временно «отвязать» базу от РИБ, чтобы принудительно обновить её структуру. Проанализируем пример кода для программного отключения главного узла:
// Процедура для снятия признака подчиненного узла РИБ
Процедура ОтключитьГлавныйУзел()
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Сообщить("База успешно отвязана от главного узла. Теперь вы можете вносить изменения в структуру.");
КонецПроцедуры
После этого выполним следующие действия:
.cf из центральной базы.
// Процедура для восстановления привязки к РИБ
Процедура УстановитьГлавныйУзел(СсылкаНаУзел)
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзел);
Сообщить("Связь с главным узлом восстановлена.");
КонецПроцедуры
Если манипуляции с .cf не помогают, значит проблема глубже — в таблице DBSchema. Рассмотрим, как это исправить встроенными средствами. Запустим «Тестирование и исправление» со следующими настройками:
Config их физическому воплощению.Посмотрим на ситуацию критически: если ТиИ не находит ошибок, а реквизит все еще «мелькает», остается радикальный, но действенный метод — выгрузка в .dt и загрузка обратно. При загрузке .dt-файла 1С полностью пересоздает структуру таблиц в базе данных SQL (или файле 1CD), отсекая все, что не описано в метаданных текущей конфигурации.
Если мы работаем с MS SQL Server или PostgreSQL, мы можем напрямую проверить наличие колонки. Выясним имя таблицы документа с помощью функции ПолучитьСтруктуруХраненияБазыДанных(). Если в SQL таблице _Document123 колонка _Fld456 (соответствующая нашему реквизиту) существует, а в Конфигураторе реквизита нет — это прямое доказательство разрушения метаданных.
В таком случае помогает выполнение так называемого «пустого» обновления:
Проверка_Удалить).Такая манипуляция заставляет платформу полностью пересчитать структуру таблицы документа в БД и часто «вычищает» фантомные поля.
Разберем краткий итог наших действий. Если в РИБ базы «разъехались» по метаданным:
snccntx) и клиента..cf из периферийной базы с центральной..cf, делаем Тестирование и исправление и привязываем узел обратно.Помните, что работа с метаданными требует осторожности: всегда делайте резервную копию перед любыми манипуляциями с планами обмена и загрузкой конфигураций.