К статье
Практический материал

Разработка и Конфигурация · 9 мин

Как проверить битые ссылки в запросе 1С

Как найти битые ссылки в 1С с помощью запроса: проверка через ISNULL, соединения с объектными таблицами, типовые инструменты и типичные ошибки разработчика.

Битая ссылка в 1С — это ссылочное значение, которое хранится в реквизите или регистре, но объект, на который оно указывает, уже удалён из базы физически. При обращении к такому значению платформа возвращает представление вида «<Объект не найден> (77:8b9a...)», а попытка получить объект через метод ПолучитьОбъект() вызывает ошибку. Такие ссылки появляются после непосредственного удаления данных, обменов с ошибками, восстановления из копий и некорректных доработок.

Проблема в том, что битая ссылка выглядит как обычное значение: она не равна NULL и не является пустой ссылкой, поэтому простая проверка «Ссылка = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка)» её не отловит. Надёжный способ найти битые ссылки — запрос с соединением к таблице самого объекта и проверкой результата на NULL. Ниже разберём рабочие конструкции, их ограничения и типовые инструменты платформы.

Что такое битая ссылка и как она ведёт себя в запросе

При прямом удалении объекта без контроля ссылочной целостности в базе остаются «висячие» значения: уникальный идентификатор записан, но строки в таблице объекта нет. Платформа хранит такие ссылки как есть и не удаляет их автоматически. В запросе битая ссылка отличается от нормальной тем, что соединение с таблицей объекта по ней не даёт результата — именно это свойство и используется для поиска.

Важно различать три состояния реквизита: пустая ссылка (объект существует как предопределённое пустое значение), NULL (отсутствие значения, например, в результате соединения) и битая ссылка (значение есть, объекта нет). Проверка «ЕСТЬ NULL» в запросе работает только для третьего случая через соединение, а не для прямого сравнения значения реквизита.

Основной способ: левое соединение с проверкой ISNULL

Классическая конструкция для поиска битых ссылок выглядит так: выбираем записи из таблицы, где хранится ссылка, присоединяем объектную таблицу по этой ссылке и оставляем только строки, где поле соединённой таблицы равно NULL. Если соединение не нашло пару — объект удалён.

ВЫБРАТЬ

Реализация.Ссылка КАК Документ,

Реализация.Контрагент КАК БитаяСсылка

ИЗ

Документ.РеализацияТоваровУслуг КАК Реализация

ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты

ПО Реализация.Контрагент = Контрагенты.Ссылка

ГДЕ

Контрагенты.Ссылка ЕСТЬ NULL

И НЕ Реализация.Контрагент = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)

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

Если реквизит составного типа (например, «Покупатель» может быть контрагентом или физлицом), соединение нужно делать с каждой таблицей из состава типа отдельно, а условие строить через И: битой считается ссылка, которая не нашлась ни в одной из таблиц. Альтернатива — проверка через ВЫРАЗИТЬ и ТИПЗНАЧЕНИЯ, но соединения надёжнее и читаемее.

Порядок действий
  1. 1
    Определите таблицу и реквизит, где может храниться битая ссылка
  2. 2
    Напишите запрос с левым соединением к объектной таблице по полю ссылки
  3. 3
    Добавьте условие: поле соединённой таблицы ЕСТЬ NULL
  4. 4
    Исключите пустые ссылки через сравнение с ЗНАЧЕНИЕ(...ПустаяСсылка)
  5. 5
    Выполните запрос в консоли запросов и проверьте выборку вручную
  6. 6
    Принимайте решение: очистить реквизит, заменить значение или восстановить объект

Проверка через консоль запросов и кодом

Для разовой диагностики удобнее всего консоль запросов: вставляете текст запроса, выполняете и сразу видите список документов или регистров с битыми ссылками. В типовых конфигурациях на БСП есть встроенная консоль в разделе администрирования, для остальных баз подойдёт любая внешняя консоль с диска ИТС или из открытых источников.

Программно результат проверки обрабатывается обходом выборки. Не пытайтесь проверять ссылку обращением к её реквизитам в цикле — это порождает запросы к базе на каждую итерацию и приводит к ошибкам. Правильный подход: один запрос с соединением, затем обход выборки и исправление данных транзакционно.

Запрос = Новый Запрос(ТекстЗапроса);

Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл

ДокументОбъект = Выборка.Документ.ПолучитьОбъект();

ДокументОбъект.Контрагент = Справочники.Контрагенты.ПустаяСсылка();

ДокументОбъект.Записать();

КонецЦикла;

Типовые инструменты платформы и конфигураций

Запрос — не единственный способ. В платформе есть штатный механизм «Удаление помеченных объектов»: он проверяет ссылочную целостность и не даёт удалить объект, пока на него есть ссылки. Если пользоваться только им, битые ссылки практически не появляются. Проблемы возникают в основном из-за обменов, прямых запросов к СУБД и внешних обработок.

В конфигурациях на Библиотеке стандартных подсистем доступна обработка «Поиск и удаление дублей», а также инструменты группового изменения реквизитов, которыми можно массово очистить найденные битые значения. Для регистров сведений и накопления проверяйте измерения и реквизиты с ссылочным типом тем же приёмом с соединением.

Сравнение вариантов поиска

Запрос с соединением и ISNULL

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

Удаление помеченных объектов

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

Перебор объектов в коде

Гибко, можно сразу исправлять. Медленно на больших объёмах и рискованно без транзакций.

Тестирование и исправление (ТиИ)

Проверяет целостность всей базы. Долго, требует монопольного доступа, не заменяет точечный анализ.

Частые ошибки и ограничения метода

Первая ошибка — забыть исключить пустые ссылки, из-за чего отчёт о «битых» значениях раздувается в десятки раз. Вторая — проверять соединение по полю, которое может быть заполнено не всегда: соединяйтесь строго по полю Ссылка объектной таблицы, это единственный гарантированный ключ. Третья — пытаться найти битые ссылки сравнением представления: строковое сравнение с «<Объект не найден>» ненадёжно и зависит от локали.

Отдельное ограничение касается составных типов и планов обмена: ссылка может указывать на объект узла, который ещё не загружен, — формально она битая, но после обмена «оживёт». Поэтому в распределённых базах перед очисткой проверяйте, не связано ли значение с незавершённой миграцией данных.

Типичные ошибки
01
Не исключены пустые ссылки — в результат попадают тысячи корректных незаполненных значений
02
Соединение не по полю Ссылка — часть реальных объектов ошибочно считается удалёнными
03
Проверка реквизита через точку в цикле — обращение к битой ссылке вызывает исключение и обрывает обработку
04
Массовая замена ссылок без резервной копии — при ошибке восстановить данные нечем
05
Очистка ссылок в распределённой базе до завершения обмена — удаляются значения, которые ещё должны загрузиться

Как проверить результат исправления

После очистки или замены значений выполните тот же запрос повторно: выборка должна стать пустой. Затем проверьте смежные места — тот же реквизит в табличных частях документов, в регистрах сведений и накопления, в движениях. Битая ссылка редко живёт в одном месте: если контрагент удалён, «хвосты» обычно остаются в нескольких объектах.

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

Контрольные точки

Как проверить результат

Повторный запрос с соединением
Норма

Выборка пустая, битых ссылок не найдено

Тревожный признак

Остались записи — проверьте табличные части и регистры

Открытие исправленного документа
Норма

Реквизиты отображаются, проведение проходит без ошибок

Тревожный признак

Появляется «Объект не найден» или ошибка записи

Отчёты по затронутым данным
Норма

Итоги соответствуют ожиданиям

Тревожный признак

Суммы изменились после замены ссылок в проведённых документах

FAQ: частые вопросы о битых ссылках в запросах 1С

Можно ли найти битую ссылку без соединения таблиц?

Надёжного способа нет. Сравнение с пустой ссылкой и проверка на NULL битую ссылку не выявляют, а сравнение строкового представления ненадёжно. Левое соединение с объектной таблицей — стандартный и единственный корректный приём в языке запросов.

Почему запрос показывает битые ссылки, которых «нет» при ручной проверке?

Чаще всего это пустые ссылки, не исключённые условием запроса, либо соединение построено не по полю Ссылка. Добавьте условие на неравенство пустой ссылке и проверьте предложение ПО в соединении.

Как проверить битые ссылки сразу по всей конфигурации?

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

Чем битая ссылка отличается от пометки удаления?

Помеченный объект физически существует в базе, соединение с ним работает, и запрос его находит. Битая ссылка указывает на уже удалённый объект — соединение не срабатывает, а обращение к реквизитам вызывает ошибку.

Опасно ли очищать битые ссылки в проведённых документах?

Да. Запись документа может перезаписать движения по регистрам и изменить итоги. Работайте в копии базы, по возможности очищайте реквизиты без перепроведения и сверяйте отчёты до и после.

Откуда берутся битые ссылки, если удаление всегда через контроль целостности?

Типичные источники — обмены данными с ошибками, восстановление из неполных копий, прямые манипуляции с таблицами СУБД и внешние обработки, удаляющие объекты в обход штатных механизмов.

Итог

Что важно запомнить

Битую ссылку в запросе 1С находят левым соединением с объектной таблицей и условием ЕСТЬ NULL по её полю Ссылка, обязательно исключая пустые ссылки. Массовые исправления выполняйте только после резервного копирования и проверяйте результат повторным запросом и сверкой итогов.