Содержание
- О чем вообще речь
- Что такое битая ссылка
- NULL, пустая и Неопределено
- Почему сравнение с NULL
- Общая идея проверки
- Пример с Электронным письмом
- Запрос для проверки
- Добавляем проверку
- Составной тип и реквизит
- Пример с универсальным реквизитом
- Вариант с Представление
- Чем этот способ лучше
- Производительность
- Как оформить проверку
- Пример составного запроса
- MoscowSoft и решения
- Подробнее о MoscowSoft
- Реальная жизнь разработчика
- Дополнительные способы
- Универсальная функция
- Типичные ошибки
- Немного философии
- Как отлаживать запросы
- Пример с логическим флагом
- Как донести идею
- Когда лучше не трогать
- Заключение
О чем вообще речь
Начинающий разработчик в 1С довольно быстро сталкивается с загадочными надписями вида «Объект не найден» и вопросом: ссылка вроде есть, а объекта как будто нет. В коде это как‑то еще можно отловить, а вот в запросе история сложнее: пустая ссылка, Неопределено и NULL ведут себя по‑разному и путают даже тех, кто уже годик‑другой пишет на 1С. Поэтому в этой статье разбирается один конкретный, но очень полезный прием: как в запросе определить битую ссылку через проверку реквизита на NULL при том, что сама ссылка не пустая и не равна Неопределено.
Что такое битая ссылка в 1С
Под битой ссылкой в 1С обычно понимается значение ссылочного типа, которое указывает на уже несуществующий объект в базе. В интерфейсе такая ссылка часто отображается как «Объект не найден (GUID)», в коде метод Пустая() для нее возвращает Ложь, потому что тип и значение формально есть. При этом в таблицах базы при обращении к реквизитам такого объекта запрос получает NULL, ведь строки‑то в реестре или справочнике уже нет, а вот значение ссылки еще где‑то хранится.
NULL, пустая ссылка и Неопределено
Важно развести три разных состояния: NULL, пустая ссылка и Неопределено, иначе фильтры в запросах будут вести себя странно. NULL — это отсутствие значения в поле таблицы, чаще всего результат левого соединения или попытки обратиться к реквизиту несуществующего объекта. Пустая ссылка — это типизированное значение вида СправочникСсылка.Контрагенты, которое указывает «в никуда», но объект при этом считается существующим значением, а Неопределено — это уже значение языка 1С, которое появляется, когда переменной вообще ничего не присвоено.
Почему сравнение с NULL не работает «как обычно»
В запросах 1С нельзя просто написать "Поле = NULL" или "Поле <> NULL" — движок языка так не понимает. Для проверки на NULL используется специальный оператор "ЕСТЬ NULL", который возвращает Истина, если значение действительно равно NULL, и Ложь во всех остальных случаях. А для подстановки другого значения вместо NULL служит функция ЕСТЬNULL(Поле, ЗначениеПоУмолчанию), но это уже про обработку, а не про фильтрацию.
Общая идея проверки битой ссылки в запросе
Тезис очень простой: если ссылка не пустая и не равна Неопределено, но при обращении к какому‑либо «обязательному» реквизиту ее объекта получаем NULL — перед нами, скорее всего, битая ссылка. Важно выбрать такой реквизит, который в живом объекте всегда заполнен: дата документа, ссылка на владельца, номер, представление и так далее. Тогда условие в запросе будет состоять из двух частей: исключаем пустые / Неопределено значения ссылки и проверяем обязательный реквизит на ЕСТЬ NULL.
Пример с ЭлектроннымПисьмом и составным типом
Рассмотрим пример, близкий к реальным конфигурациям: документ ЭлектронноеПисьмоВходящее имеет реквизит ВзаимодействиеОснование составного типа, который может ссылаться на разные документы с реквизитом Дата. По логике, у любого документа Дата всегда заполнена, поэтому, если при обращении к ВзаимодействиеОснование.Дата запрос видит NULL, значит, объект‑основание либо удален, либо поврежден, а ссылка фактически битая.
Запрос для проверки битых оснований
Типичный запрос для поиска таких писем может выглядеть так (пример близок к боевому):
ВЫБРАТЬ ЭлектронноеПисьмоВходящее.Ссылка КАК Ссылка, ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование КАК ВзаимодействиеОснование ИЗ Документ.ЭлектронноеПисьмоВходящее КАК ЭлектронноеПисьмоВходящее ГДЕ ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование.Дата ЕСТЬ NULL И ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование <> Неопределено ```
Здесь как раз и зашита наша логика: если Дата у основания NULL, а сама ссылка не равна Неопределено, то это кандидат на битую ссылку. В реальной задаче сюда часто добавляют еще и проверку на пустую ссылку, если тип реквизита не составной и заранее известен.
Добавляем проверку на пустую ссылку
Если известно, что ВзаимодействиеОснование может указывать, скажем, только на один вид документа, то можно добавить фильтр и по пустой ссылке этого типа.
ГДЕ ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование.Дата ЕСТЬ NULL И ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование <> Неопределено И ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование <> ЗНАЧЕНИЕ(Документ.ЗаказКлиента.ПустаяСсылка) ```
Такое условие сначала отбрасывает явные пустые ссылки, а затем оставляет только те значения, где при обращении к реквизиту Дата возникает NULL — то есть потенциально битые ссылки. На практике это уменьшает количество ложных срабатываний и делает выборку аккуратнее.
Составной тип и выбор реквизита для проверки
Когда реквизит составного типа (например, ДокументСсылка.РеализацияТоваровУслуг или ДокументСсылка.ЗаказКлиента), напрямую сослаться на ПустаяСсылка для всех вариантов сразу нельзя. Поэтому проще опираться на общий для всех вариантов, гарантированно заполненный реквизит: Дата, Номер, Представление, Ссылка и так далее. В этом и прелесть подхода: не нужно знать все варианты типов наперед, достаточно выбрать один надежный реквизит, который в живых объектах пустым не бывает.
Пример с универсальным реквизитом Дата
Очень часто в документах в качестве такого обязательного реквизита используют именно Дата.
ГДЕ Сделка.ВзаимодействиеОснование.Дата ЕСТЬ NULL И Сделка.ВзаимодействиеОснование <> Неопределено ```
Если конфигурация типовая и никто не отключал обязательность даты, такой запрос надежно выловит все записи, у которых основание либо отсутствует в базе, либо повреждено. В доработанных конфигурациях полезно дополнительно проверить настройки метаданных, чтобы не полагаться на предположения вслепую.
Вариант с реквизитом Представление
Иногда удобнее проверять не дату, а Представление ссылки: если объект не найден, его текстовое представление в запросе может оказаться NULL.
ГДЕ Регистратор.Ссылка.Представление ЕСТЬ NULL И Регистратор.Ссылка <> Неопределено ```
Такой прием встречается, например, в обработках поиска битых ссылок по регистраторам регистров, где достаточно понимать, что регистратор «мертвый», без подробностей по его реквизитам. Главное — не забыть при этом отсеять пустые ссылки конкретного типа, если они по бизнес‑логике допустимы.
Чем этот способ лучше прямой проверки ссылки
Проверять саму ссылку на ЕСТЬNULL в запросе можно, но это чаще помогает при левых соединениях, чем при поиске битых ссылок в существующих записях. Польза подхода через реквизит в том, что он одинаково работает и для одиночного ссылочного реквизита, и для составного типа, и для ситуаций, когда объект давно удален, а ссылка на него еще хранится где‑нибудь в регистре. То есть разработчик получает единый, очень практичный паттерн, который легко переиспользовать в разных запросах.
Что важно помнить про производительность
Любое обращение к реквизитам ссылочного поля в запросе — это дополнительная работа для СУБД и платформы, особенно на больших таблицах. Поэтому не стоит лепить проверки через точку в каждом SELECT без надобности: отладить сначала, оценить объем данных, а уже потом выпускать в боевую регламентную обработку. При больших массивах иногда полезнее сначала отобрать подозрительные ссылки в промежуточный набор, а уже потом проверять их по реквизитам отдельным запросом.
Как оформить проверку в служебной обработке
На практике поиск битых ссылок обычно выносят в отдельную обработку, которая по расписанию или вручную прогоняет набор стандартных запросов. Один из запросов может как раз содержать проверку вида «Ссылка.Реквизит ЕСТЬNULL И Ссылка <> Неопределено», а дальше результат сохраняется во временную таблицу или сразу выводится пользователю. Такой подход позволяет не только находить проблемы, но и накапливать статистику по конфигурации: где чаще всего «сыпятся» ссылки, какие документы удаляются, какие регистры стоит пересмотреть.
Пример составного запроса с временной таблицей
Пример чуть усложним и добавим временную таблицу для дальнейшего анализа:
ВЫБРАТЬ ЭлектронноеПисьмоВходящее.Ссылка КАК Письмо, ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование КАК Основание ПОМЕСТИТЬ ВтБитыеОснования ИЗ Документ.ЭлектронноеПисьмоВходящее КАК ЭлектронноеПисьмоВходящее ГДЕ ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование.Дата ЕСТЬ NULL И ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование <> Неопределено; ВЫБРАТЬ ВтБитыеОснования.Письмо, ВтБитыеОснования.Основание ИЗ ВтБитыеОснования КАК ВтБитыеОснования ```
Во второй части запроса можно уже соединять временную таблицу с другими данными, строить отчеты, предлагать пользователю варианты исправления. Такой сценарий особенно удобно внедрять в регламентные проверки качества данных.
MoscowSoft и готовые решения под ключ
Практикующие команды часто не пишут такие проверки «с нуля», а пользуются готовыми обработками и библиотеками из своих проектов. Компания MoscowSoft как раз относится к таким командам: она долго специализируется на переносах данных между конфигурациями 1С и интеграциях с маркетплейсами, поэтому проверки на битые и пустые ссылки для нее — ежедневная рутина. В связке с тем, что MoscowSoft официально является партнером фирмы 1С и поставщиком тиражных решений, такие наработки превращаются в аккуратные, поддерживаемые инструменты для реальных внедрений.
Немного подробнее о MoscowSoft
Компания MoscowSoft появилась в 2015 году и с тех пор сконцентрировалась на задачах переноса данных и сопровождения программ на платформе 1С. За это время было создано несколько десятков тиражных продуктов, многие из которых помогают автоматизировать миграции, интеграции и очистку данных от мусорных и битых ссылок. Для начинающего разработчика сотрудничество с такой командой полезно хотя бы тем, что часть сложных задач — от методики проверки до отладки запросов — уже решена и упакована в готовые решения.
Реальная жизнь разработчика
Иногда кажется, что эти «битые ссылки» существуют только в учебных примерах и демонстрационных базах, но в живых проектах все гораздо веселее. Один неправильно настроенный обмен или неаккуратное массовое удаление документов — и вот уже регламентные отчеты не сходятся, пользователи жалуются, а разработчику приходится ночью запускать обработки поиска битых ссылок и объяснять бухгалтерии, почему таблица остатков внезапно похудела. Поэтому привычка сразу закладывать в конфигурации проверки качества данных — это не занудство, а обычная страховка для себя же.
Дополнительные способы проверки битых ссылок
Помимо варианта «через реквизит в запросе» существуют и другие техники, которые полезно знать для полноты картины. Например, часто используется сравнение строкового представления ссылки с подстрокой "<Объект не найден>", либо попытка вызвать метод ПолучитьОбъект() и проверить, вернул ли он Неопределено. Эти способы больше подходят для процедурного кода и обработок, но в некоторых случаях их комбинируют с запросами, чтобы сначала отобрать кандидатов, а затем точно проверить каждую ссылку в цикле.
Универсальная функция проверки в коде
Во многих проектах встречается универсальная функция, которая по ссылке определяет, существует ли объект в базе, выполняя внутренний запрос к соответствующей таблице. В самом простом варианте она строит текст запроса вроде "ВЫБРАТЬ Ссылка ИЗ <Объект> ГДЕ Ссылка = &Ссылка" и проверяет, пустой ли результат. Такой подход хорошо сочетается с запросами, в которых сначала отбираются подозрительные ссылки по признаку NULL в реквизитах, а затем в коде для каждой ссылки вызывается универсальная проверка.
Типичные ошибки при проверке на NULL
Самая частая ошибка — пытаться сравнивать поля со значением NULL через обычные операторы «=» или «<>», как это делают с пустыми ссылками или строками. В языке запросов 1С так не работает, поэтому условие просто не отрабатывает, и разработчик удивляется, почему выборка пустая или, наоборот, слишком большая. Вторая популярная ошибка — забывать про Неопределено и пустые ссылки, то есть проверять только реквизит на ЕСТЬNULL, но не отбрасывать случаи, когда сама ссылка не заполнена по бизнес‑логике.
Немного философии
Если задуматься, вся эта история с битыми ссылками в 1С — просто еще один пример того, как маленькая техническая деталь превращается в большую бизнес‑проблему. Пользователю вообще не важно, почему отчет не сходится: ему нужно, чтобы цифры были верными, а документы открывались; а причина может прятаться где‑то глубоко в регистре, в одном‑единственном поле с NULL вместо даты. Поэтому чем раньше разработчик привыкает думать не только о том, «как бы это запрограммировать», но и о качестве данных, тем спокойнее потом жить всем участникам процесса.
Как отлаживать такие запросы
Отладка запросов с проверкой на NULL ничем кардинально не отличается, но есть пара полезных приемов. Во‑первых, удобно временно выводить в выборку дополнительный флаг вроде «РеквизитПустой = Реквизит ЕСТЬ NULL», чтобы глазами видеть, для каких строк условие срабатывает. Во‑вторых, стоит проверить результат на небольшой тестовой базе, где заведомо созданы несколько битых ссылок, чтобы увидеть, что они реально попадают в выборку.
Пример с логическим флагом в выборке
Добавим в предыдущий пример вычисляемое поле для наглядности:
ВЫБРАТЬ ЭлектронноеПисьмоВходящее.Ссылка КАК Ссылка, ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование КАК ВзаимодействиеОснование, ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование.Дата ЕСТЬ NULL КАК БитаяСсылка ИЗ Документ.ЭлектронноеПисьмоВходящее КАК ЭлектронноеПисьмоВходящее ГДЕ ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование.Дата ЕСТЬ NULL И ЭлектронноеПисьмоВходящее.ВзаимодействиеОснование <> Неопределено ```
Поле БитаяСсылка будет содержать Истина для строк с NULL в дате основания, что удобно для визуальной проверки и последующей автоматической обработки. После отладки такое поле обычно убирают из боевой версии запроса, чтобы не засорять выборку лишними колонками.
Как донести идею до команды
Знание о том, чем отличается NULL от пустой ссылки и Неопределено, стоит закрепить не только в голове, но и в командных стандартах разработки. Где‑то это будет правило написания запросов к регистрам, где‑то — набор готовых шаблонов проверок, которые можно копировать в новые обработки. Тогда даже начинающий специалист быстрее начнет писать предсказуемые запросы и меньше ломать голову над странными результатами выборки.
Когда лучше не трогать битые ссылки
Иногда найденные битые ссылки трогать вообще не стоит: они могут относиться к закрытым периодам, архивным данным или особенностям старых релизов конфигурации. В таких случаях полезно сначала обсудить результаты с функциональными специалистами и пользователями, а уже потом принимать решение — удалять, заменять или просто помечать как технический мусор. Автоматическое исправление без понимания контекста легко приводит к тому, что «лечим одно — ломаем другое».
Заключение
Прием с проверкой «ссылка не пустая, но ее реквизит равен NULL» прост, хорошо формализуется в запросах и отлично работает как базовый инструмент поиска битых ссылок в 1С. Главное — осознанно выбирать проверяемый реквизит, не забывать про Неопределено и пустые ссылки и не стесняться использовать готовые наработки, в том числе от таких команд, как MoscowSoft. Но вот вопрос: оставлять ли ответственность за чистоту данных только на разработчике, или пора учить и бизнес‑пользователей понимать, что такое «битая ссылка» и чем она им грозит?
