В процессе эксплуатации распределенных информационных баз (РИБ) администраторы и программисты 1С часто сталкиваются с ситуацией, когда данные между узлами передаются успешно, но изменения метаданных (конфигурации) игнорируются подчиненным узлом. Вроде бы файл обмена содержит блок конфигурации, но заветный «восклицательный знак» в конфигураторе подчиненного узла не появляется, а при попытке обмена система выдает ошибку о несовпадении конфигураций. Проанализируем причины этой проблемы и разберем по шагам методы её решения.
Как показывает практика и обсуждение в рассматриваемой теме, наиболее частой причиной «невидимости» обновлений является некорректная работа локального кэша платформы 1С. Система может «считать», что она уже применила изменения, или просто использовать старые описания метаданных из временных файлов. Для точечного поиска и удаления временных файлов конкретной базы подойдёт утилита для сопоставления и очистки локального кэша 1С.
Рассмотрим процедуру полной очистки кэша. Самый надежный способ — это удаление базы из списка информационных баз и её повторное добавление. При этом папка с кэшем, привязанная к идентификатору базы (GUID), перестанет использоваться. Если же мы хотим подойти к вопросу профессионально, выполним следующие действия:
%AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\).Если простая очистка кэша не помогла, воспользуемся радикальным, но крайне эффективным методом: временным «отвязыванием» базы от центрального узла. Это позволит нам вручную загрузить конфигурацию .cf и вернуть базу в строй. Проанализируем этот алгоритм подробнее.
Для начала нам необходимо снять признак того, что база является подчиненной. Для этого в конфигураторе периферийного узла откроем внешнюю обработку или создадим новый код:
// Снимаем привязку к центральному узлу
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода база становится автономной. Теперь мы можем выполнить следующие шаги:
1cv8.cf).
// Восстанавливаем привязку к центральному узлу
УзелЦентра = ПланыОбмена.Полный.НайтиПоКоду("ЦБ"); // "ЦБ" — код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентра);
Важно помнить: перед выполнением этих операций обязательно создайте резервные копии обеих баз!
Выясним еще одну неочевидную причину: рассинхронизация номеров сообщений. Механизм РИБ устроен так, что если номер входящего сообщения меньше или равен номеру последнего принятого сообщения, платформа может проигнорировать содержимое файла, включая блок изменений конфигурации.
Посмотрим на ситуацию со стороны системы: она видит файл, но «думает», что эти данные уже обрабатывались. Чтобы исправить это, нужно зайти в подчиненный узел и программно уменьшить номер принятого сообщения. Например, если пришел файл номер 100, а в базе записано, что принято сообщение 100, изменим значение на 99.
// Корректировка номера сообщения
УзелОбъекта = УзелЦентра.ПолучитьОбъект();
УзелОбъекта.НомерПринятого = 99;
УзелОбъекта.Записать();
Разберем влияние современных механизмов платформы на процесс обновления. Начиная с версий 8.3.12 и 8.3.15, 1С активно использует расширения конфигурации. Если в подчиненном узле подключено расширение, которое «зацепляет» изменяемые объекты, это может блокировать применение основной конфигурации. Для быстрой деактивации или удаления модификаций можно использовать обработку для группового управления расширениями конфигурации.
Проанализируем наши действия в этом случае:
Если штатные средства графического интерфейса не срабатывают, мы можем попробовать принудительно обновить конфигурацию базы данных через параметры запуска. Это позволяет обойти некоторые проверки интерфейса.
Запустим командную строку и выполним команду следующего вида:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "ПутьКВашейБазе" /UpdateDBCfg -Force
Параметр -Force заставляет систему игнорировать некоторые предупреждения и принудительно сопоставлять структуру метаданных с базой данных.
В редких случаях проблема кроется в самой центральной базе. Если в конфигурации «центра» есть объекты с нарушенной целостностью (например, тип реквизита ссылается на удаленный объект метаданных), то выгрузка будет содержать некорректное описание. Подчиненный узел, пытаясь прочитать такой XML, просто «проглатывает» ошибку и не инициирует обновление.
В такой ситуации поможет процедура «Тестирование и исправление» в центральной базе. Обязательно выберите пункты «Проверка логической целостности» и «Проверка ссылочной целостности». После исправления ошибок в центре сделайте повторную выгрузку в подчиненный узел.
Подведем итог: если конфигурация не загружается, начните с очистки кэша. Если это не помогает, используйте метод отвязки от центрального узла с ручной загрузкой .cf. Эти два способа решают 95% подобных проблем в распределенных системах на базе 1С.