Как исправить ошибку «Табличная часть имеет записи, не относящиеся ни к одной записи главной таблицы» при тестировании и исправлении в 1С?

← На главную

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

Причины возникновения «осиротевших» записей

Табличные части справочников и документов в 1С физически хранятся в отдельных таблицах СУБД (как в файловой базе .1CD, так и в MS SQL Server, PostgreSQL и др.). Связь строки табличной части с объектом-владельцем осуществляется по внутреннему идентификатору ссылки (полю _Reference_IDRRef или аналогичному).

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

Насколько критична эта ошибка?

Проанализируем риски, возникающие при наличии записей-сирот в информационной базе:

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

Таким образом, оставлять эту ошибку без внимания не рекомендуется — базу данных необходимо восстановить до консистентного состояния.

Как найти некорректные записи через консоль запросов

Прежде чем выполнять исправление, мы можем локализовать поврежденные строки с помощью простого запроса в пользовательском режиме. Выполним проверку на наличие записей, у которых родительский объект отсутствует (равен NULL):


ВЫБРАТЬ
    ТЧ.Ссылка КАК БитыйЭлемент,
    ТЧ.НомерСтроки КАК НомерСтроки
ИЗ
    Справочник.ИмяСправочника.ИмяТабличнойЧасти КАК ТЧ
ГДЕ
    ТЧ.Ссылка.Наименование ЕСТЬ NULL

Если запрос возвращает строки, значит, в табличной части действительно присутствуют осиротевшие данные, подлежащие удалению.

Способ 1. Исправление средствами штатного тестирования и исправления (ТИИ)

Штатный механизм конфигуратора позволяет полностью удалить некорректные записи. Разберем по шагам правильный порядок действий:

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

В ходе исправления логической целостности платформа автоматически обнаружит строки табличной части без главного объекта и удалит этот мусор.

Способ 2. Восстановление файловой базы через chdbfl.exe и перевыгрузку

Если информационная база работает в файловом режиме (файл 1Cv8.1CD), можно применить следующие действия:

Завершим все сеансы пользователей и сделаем копию файла базы.
Запустим утилиту проверки физической целостности chdbfl.exe (находится в каталоге bin установленной платформы 1С).
Установим флаг «Исправлять обнаруженные ошибки» и выполним сканирование. Утилита очистит некорректные страницы и невалидные записи.
Дополнительно выполним выгрузку информационной базы в файл .dt через конфигуратор и загрузим ее в новую чистую базу. При выгрузке данных в формат выгрузки платформа сериализует только валидные объекты, отсекая битые хвосты.

Способ 3. Удаление записей прямым запросом к СУБД (для клиент-серверного варианта)

В нагруженных базах на MS SQL Server или PostgreSQL, когда монопольный запуск ТИИ недоступен из-за жестких регламентных окон, администраторы могут очистить потерянные строки табличной части на уровне СУБД.

Посмотрим на алгоритм действий:

Определим физические имена таблиц с помощью метода ПолучитьСтруктуруХраненияБазыДанных().
Выполним поиск строк в таблице подчиненной части, идентификатор ссылки которых отсутствует в основной таблице справочника:
```
SELECT * FROM _ReferenceTable_VT
WHERE _Reference_IDRRef NOT IN (SELECT _IDRRef FROM _ReferenceTable);
```

Удалим осиротевшие записи:


DELETE FROM _ReferenceTable_VT
WHERE _Reference_IDRRef NOT IN (SELECT _IDRRef FROM _ReferenceTable);

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