При работе с распределенными информационными базами (РИБ) на платформе 1С:Предприятие 8.3 администраторы и разработчики часто сталкиваются с проблемой при первом запуске периферийного узла. Типичная ситуация: создание начального образа завершено успешно, однако при попытке зайти в новую базу программа выдает критическую ошибку, сообщая, что информационная база не может быть обновлена из-за проблем в главном узле. Чаще всего это связано с тем, что не были зарегистрированы для обмена приоритетные данные, в частности справочник ИдентификаторыОбъектовМетаданных.
В этой статье мы подробно разберем, почему возникает эта ошибка, как правильно настроить состав отправляемых данных и какие технические приемы помогут «реанимировать» процесс создания начального образа в конфигурациях на базе БСП (например, ЗУП 3.1, ERP или КА).
Давайте проанализируем текст типичной ошибки, которая фиксируется в журнале регистрации. Система указывает на то, что в главном узле либо не был увеличен номер версии конфигурации, либо не завершились процедуры обновления, из-за чего справочник ИдентификаторыОбъектовМетаданных оказался незаполненным или данные в нем не соответствуют текущей структуре метаданных. В современной архитектуре 1С этот справочник является фундаментом для работы всех механизмов обмена, прав доступа и программных интерфейсов.
Проблема заключается в том, что при создании начального образа система делает «слепок» данных. Если в главном узле идентификаторы метаданных не были актуализированы или не были помечены к выгрузке как приоритетные, подчиненный узел просто не сможет сопоставить объекты в файле обмена со своей внутренней структурой. Рассмотрим пошагово, как это исправить.
Первым делом нам необходимо убедиться, что главный узел действительно находится в «здоровом» состоянии. Даже если вы видите интерфейс программы, это не означает, что все фоновые процедуры обновления завершены. Проанализируем ситуацию: в конфигурациях на базе БСП обновление часто происходит в отложенном режиме.
Для принудительного запуска всех процедур обновления выполним следующие действия:
/C ЗапуститьОбновлениеИнформационнойБазы
Это действие заставляет программу выполнить все обработчики, которые могли быть пропущены или аварийно прерваны. Только после этого можно приступать к повторному созданию начального образа.
Если обновление через параметр /C не помогло, нам нужно программно пересчитать идентификаторы. Рассмотрим ситуацию, когда структура метаданных изменилась (например, после обновления конфигурации), а внутренние таблицы не обновились. Выясним причину несоответствия и устраним её с помощью кода.
Для этого откроем консоль кода или создадим внешнюю обработку и выполним следующий фрагмент:
// Программное обновление справочника идентификаторов объектов метаданных
// Параметр Истина, Истина заставляет систему полностью перезаписать данные
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Истина);
Этот метод принудительно сопоставляет каждый объект конфигурации (справочники, документы, регистры) с соответствующей записью в справочнике идентификаторов. После выполнения этого кода крайне важно убедиться, что изменения зарегистрированы для обмена в нужном узле РИБ.
Рассмотрим подробнее вопрос настройки синхронизации в главном узле. Нужно ли заходить в состав отправляемых данных и проставлять галки вручную? В идеальной ситуации система делает это автоматически, но при возникновении ошибок нам придется вмешаться.
Для исправления ситуации выполним следующие шаги:
Идентификаторы объектов метаданных.Параметры работы программы. Именно эти данные система считает «приоритетными».Важный момент: не стоит ставить «все галки» на все объекты без разбора, так как это может привести к выгрузке огромного объема лишних данных в периферийную базу, что затянет процесс создания образа на часы или даже дни. Регистрируем только системные справочники, на которые ругается программа.
Проанализируем ситуацию, если в вашей базе используются расширения. В РИБ 8.3 расширения также могут добавлять свои идентификаторы. Если версия платформы на сервере и клиенте различается или если расширение было добавлено некорректно, это вызовет ту же ошибку «Главный узел некорректно обновлен».
Посмотрим на решение: перед созданием начального образа рекомендуется убедиться, что во всех расширениях отключена опция «Использовать основные возможности» (если они не должны влиять на структуру данных в РИБ) или проверить, что расширения корректно мигрируют в подчиненный узел. В некоторых случаях помогает временное удаление расширений перед выгрузкой образа и их последующая установка уже в оба узла.
Иногда проблема кроется не в данных, а в локальном кэше метаданных. Если вы обновили конфигурацию, выполнили все скрипты, но ошибка сохраняется, попробуем очистить кэш на рабочем месте, где выполняется создание образа. Это исключит ситуацию, когда система пытается использовать старые описания типов объектов.
Также, как показывает практика обсуждений (сообщение 14), переход на более свежий релиз (например, с 3.1.8.185 на 3.1.8.214) часто содержит в себе исправления внутренних механизмов БСП, которые автоматически устраняют проблемы с регистрацией приоритетных данных. Если вы работаете на сильно доработанной конфигурации, проверьте, не затронули ли ваши изменения модули обмена и процедуры обновления ИдентификаторовОбъектовМетаданных.
Разберем краткое резюме для быстрого решения проблемы:
/C ЗапуститьОбновлениеИнформационнойБазы.ОбновитьДанныеСправочника для актуализации системных таблиц.Идентификаторы объектов метаданных.Соблюдение этого порядка действий гарантирует, что периферийный узел получит всю необходимую информацию для корректного запуска и последующей синхронизации с центральной базой.