Что делать, если реквизиты отсутствуют в конфигурации, но видны в отладчике

← На главную

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

Выясним причину возникновения фантомных реквизитов

Проанализируем техническую сторону работы платформы с расширениями. Когда мы добавляем новый реквизит в справочник через расширение, 1С не просто хранит его в памяти, а создает полноценную физическую колонку в таблице базы данных (например, в таблице _ReferenceX для MS SQL или PostgreSQL). При корректном удалении расширения платформа должна инициировать процесс реструктуризации и удалить эти колонки.

Однако, если произошел сбой в таблице метаданных самого расширения (внутренняя таблица ConfigExtension) или расширение было удалено некорректно (например, при аварийном завершении сеанса), платформа может «забыть», что реквизиты нужно удалить из SQL-таблиц. В результате:

В дереве метаданных конфигуратора реквизитов нет.
В списке «Управление расширениями» пусто.
В отладчике при просмотре структуры Объект реквизиты видны, так как платформа считывает реальный состав колонок таблицы базы данных.

Метод 1: Создание «расширения-дубликата» (наиболее эффективный)

Рассмотрим самый надежный способ заставить платформу принудительно очистить таблицы. Этот метод основан на принципе «клин клином»: мы создаем временное расширение, которое имитирует старое, и просим платформу удалить его заново.

Определим идентификаторы. Выясним точное имя «фантомных» реквизитов в отладчике. Обычно они имеют префикс, например, ид_МойРеквизит.
Создадим новое расширение. В конфигураторе добавим новое расширение. Крайне важно, чтобы его имя и префикс соответствовали тем, что были у удаленного расширения.
Добавим фантомные реквизиты вручную. В созданном расширении найдем нужный объект (например, справочник Партнеры), заимствуем его и добавим в него реквизиты с ТЕМИ ЖЕ именами и типами данных, которые мы видим в отладчике.
Применим изменения. Выполним обновление конфигурации базы данных (клавиша F7). На этом этапе платформа сопоставит наши «новые» реквизиты с теми «хвостами», что уже лежат в SQL-таблице.
Удалим реквизиты из расширения. Теперь удалим эти реквизиты из дерева метаданных расширения и снова нажмем F7. Это принудительно запустит механизм реструктуризации ALTER TABLE DROP COLUMN.
Удалим само расширение. После завершения очистки удалим само расширение из списка.

Метод 2: Очистка серверного кэша метаданных

Иногда проблема кроется не в SQL-таблицах, а в том, что сервер приложений 1С «закешировал» старую структуру метаданных. Проанализируем ситуацию: если мы используем параметр /ClearCache, мы чистим только локальный кэш пользователя, но серверный кэш (сеансовые данные) остается нетронутым.

Пошаговая инструкция по глубокой очистке сервера:

Остановим службу «Агент сервера 1С:Предприятие».
Перейдем в каталог srvinfo (путь по умолчанию: C:\Program Files\1cv8\srvinfo).
Найдем папку с идентификатором (GUID) нашей информационной базы.
Внутри этой папки полностью удалим содержимое каталогов snccntxt (сеансовые данные) и reg_XXXX.
Запустим службу сервера.

После этой процедуры сервер будет вынужден заново перечитать структуру из таблицы Config, что часто убирает видимость несуществующих объектов.

Метод 3: Использование выгрузки и загрузки конфигурации в XML

Если предыдущие методы не помогли, воспользуемся радикальным способом очистки бинарных «мусорных» связей. Выгрузка в XML позволяет избавиться от артефактов, которые могли накопиться в файле конфигурации .cf.

Рассмотрим последовательность действий:

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

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

Диагностика через «Структуру хранения базы данных»

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


ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных("Справочник.Партнеры");
Для Каждого СтрокаТаблицы Из ТаблицаСтруктуры Цикл
    Сообщить("Поле в БД: " + СтрокаТаблицы.ИмяПоляХранения + " | Имя метаданных: " + СтрокаТаблицы.ИмяПоля);
КонецЦикла;

Проанализируем результат: если в колонке ИмяПоляХранения мы видим техническое имя (например, _Fld1234_ID_EXT), а в конфигураторе этого поля нет — это прямое подтверждение того, что реструктуризация при удалении расширения не была завершена. В таком случае строго рекомендуется использовать Метод 1 (расширение-дубликат), так как прямое удаление колонок через SQL-запросы может привести к необратимому повреждению базы данных и потере поддержки со стороны вендора.

Проверка дополнительных реквизитов БСП

Напоследок разберем еще один нюанс. Если ваша конфигурация построена на базе БСП (Библиотека стандартных подсистем), проверьте, не являются ли эти поля Дополнительными реквизитами. Такие реквизиты:

Не отображаются в дереве метаданных.
Хранятся в Плане видов характеристик ДополнительныеРеквизитыИСведения.
Программно добавляются в структуру Объект при открытии формы (именно поэтому они видны в отладчике).

Если имена реквизитов в отладчике не содержат технических префиксов расширений, обязательно загляните в раздел «Администрирование — Дополнительные реквизиты» и проверьте, нет ли там созданных пользователями полей.