Что делать, если объект есть в коллекции метаданных, но отсутствует в дереве конфигурации и таблицах СУБД?

← На главную

При обновлении конфигураций (особенно типовых или использующих Библиотеку стандартных подсистем) разработчики иногда сталкиваются с ситуацией рассинхронизации метаданных: в окне дерева конфигурации объект отсутствует, но при обращении к коллекции Метаданные.Справочники через встроенный язык он отображается как существующий. При попытке выполнить запрос к такому объекту система выдает ошибку, так как физическая таблица в базе данных отсутствует. Разберем причины возникновения этой коллизии и пошаговые методы её устранения.

Причины возникновения рассинхронизации метаданных

Проанализируем архитектуру хранения конфигурации в платформе 1С:Предприятие, чтобы понять природу ошибки:

Расхождение между слоями конфигурации. В платформе 1С дерево объектов в Конфигураторе формируется на базе редактируемой конфигурации (таблица ConfigSave), в то время как программный контекст Метаданные в режиме Предприятия опирается на конфигурацию базы данных (таблица Config). Если в процессе обновления удаление объекта прошло в дереве, но не зафиксировалось в физической схеме БД, объект пропадает из дерева, но остается в контексте запущенного сеанса.
Сбои механизма динамического обновления. При частом применении динамического обновления в служебных таблицах накапливаются версионные записи. При аварийном завершении сеанса они могут зависнуть, порождая «фантомные» объекты метаданных.
Кэширование на стороне кластера серверов. Служба rphost кэширует схему метаданных. Очистка кэша только на клиенте не сбрасывает данные кластера, и сеансы продолжают видеть удаленный объект в глобальной коллекции.

Способ 1. Принудительное обновление структуры через добавление фиктивного объекта

Самый быстрый и действенный способ заставить платформу выполнить полную сверку и актуализацию дерева конфигурации с конфигурацией базы данных — внести контролируемое изменение в структуру.

Разберем процесс по шагам:

Откроем дерево конфигурации в режиме Конфигуратор.
Добавим новый фиктивный объект метаданных (например, новый временный справочник с именем ВременныйСправочникДляСинхронизации).
Удалим только что созданный объект из дерева конфигурации.
Нажмем клавишу F7 (или пункт меню «Конфигурация — Обновить конфигурацию базы данных»).
Подтвердим реструктуризацию и применим изменения.

Данная процедура инициирует внутреннюю перепроверку хеш-сумм описаний метаданных между слоями ConfigSave и Config, благодаря чему платформа удаляет зависшие фантомные записи из метаданных базы.

Способ 2. Программная диагностика физических таблиц

Чтобы точно определить, существует ли физическая таблица для спорного объекта в базе данных, воспользуемся методом встроенного языка ПолучитьСтруктуруХраненияБазыДанных().

Посмотрим на пример диагностического кода:


ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных();
НайденныеТаблицы = ТаблицаСтруктуры.НайтиСтроки(Новый Структура("ИмяМетаданных", "Справочник.ПериодыЦикличности"));

Если НайденныеТаблицы.Количество() = 0 Тогда
    Сообщить("Физическая таблица для объекта отсутствует в структуре СУБД!");
Иначе
    Для Каждого Стр Из НайденныеТаблицы Цикл
        Сообщить("Имя таблицы хранения: " + Стр.ИмяТаблицыХранения);
    КонецЦикла;
КонецЕсли;

Если метод подтверждает отсутствие таблицы хранения при наличии объекта в коллекции Метаданные, требуется принудительная реинициализация метаданных конфигурации.

Способ 3. Пересборка метаданных через выгрузку и загрузку конфигурации

Если простое сохранение не помогло, устраним скрытые ошибки структуры с помощью перезаписи файла конфигурации:

Выполним выгрузку конфигурации: меню «Конфигурация — Сохранить конфигурацию в файл...» (сохраняем файл с расширением .cf).
Выполним команду «Конфигурация — Загрузить конфигурацию из файла...» и укажем сохраненный .cf-файл. Полная загрузка перезаписывает таблицы метаданных целиком, в отличие от механизма сравнения и объединения.
Альтернативный вариант для глубокой очистки дерева: выполнить команду «Конфигурация — Выгрузить конфигурацию в файлы...» (в формате XML) и затем выполнить «Конфигурация — Загрузить конфигурацию из файлов...». Это гарантированно удаляет некорректные внутренние ссылки на отсутствующие объекты.
Применим изменения по F7.

Способ 4. Очистка серверного кэша и перезапуск процессов

В клиент-серверном варианте работы фантомные метаданные могут удерживаться рабочими процессами сервера 1С. Выполним полную очистку кэша кластера:

Завершим все сеансы пользователей и остановим службу Агент сервера 1С:Предприятия.
Перейдем в каталог данных кластера (по умолчанию: C:\Program Files\1cv8\srvinfo\).
Очистим временные подкаталоги сеансовых данных и кэша метаданных: папки с именами вида snccntx*, sneg*, а также папки кэша внутри каталогов баз с GUID-именами. Важно: не удаляйте конфигурационные файлы кластера 1CV8Clst.lst, 1cv8wsregistry.lst.
Запустим службу сервера 1С:Предприятия заново.

Способ 5. Актуализация служебных данных БСП

Если расхождение касается подсистем БСП (например, справочников идентификаторов объектов метаданных), необходимо выполнить обновление служебных данных. Для этого запустим 1С:Предприятие со специальным параметром командной строки:

1cv8.exe ENTERPRISE /IBConnectionString "..." /C ЗапуститьОбновлениеИнформационнойБазы

Также можно воспользоваться специализированной обработкой обновления служебных данных из состава инструментария разработчика БСП, поставляемой вместе с библиотекой.