Прошу совета в таком вопросе.
Есть распределенная база. Есть регистр сведений и там есть параметры из другой базы вида <Объект не найден>.
ак нам в запросе исключить эти элементы?
Типа использовать подобие или еще что?
Я пока нашел только один выход - ВНУТРЕННЕЕ СОЕДИНЕНИЕ с со значениями этого реквизита Регистра.
Соответственно объекты  <Объект не найден> не попадут.
Есть ли другой вариант?

Попробуйте в ГДЕ указать ПолеРегистраСведений ЕСТЬ NULL
или ПолеРегистраСведений.Представление ЕСТЬ NULL

Точнее наоборот :)
НЕ ЕСТЬ NULL

(1)он не NULL а <Объект не найден>

(2)не пройдет

РАЗРЕШЕННЫЕ
правда помоему только в корневых объектах выборки помоему. на реквизитах не сработает :)

(0) исправить ситуацию не предлагать?

(6) согласен. такой ситуации в корне быть не должно. значит у него и в журналах и в списках все это торчит.

(0) Ну и правильно. В чем вопрос-то?

(3) Рискну предположить, что представление <Объект не найден> будет, все таки, NULL

(9) нет, неправильно

+10 есть ссылка, но нет объекта, значение - строка(36)

Где Реквизит.Ссылка Есть не NULL

Где Таблица.Реквизит.Ссылка Есть не NULL

все реквизиты у <Объект не найден> будут NULL

(12) +1

Короче, быстрее и правильнее оказалось вариант сделанный мной - со ВНУТРЕННИМ СОЕДИНЕНИЕМ

Проверил:

ВЫБРАТЬ
   РегистрСведений1.Справочник1,
   РегистрСведений1.Ресурс1
ИЗ
   РегистрСведений.РегистрСведений1 КАК РегистрСведений1
   ГДЕ НЕ (Справочник1.Представление ЕСТЬ NULL)

Вот эта штука выбирает все строки регистра, у которых в измерении нет <Объект не найден>

(16) И?
Это же очевидно. Если ссылка на реквизит битая, т.е. поле заполнено неким значением и не есть NULL, но отсутствует в целевой таблице.

(17) Неявное внутреннее соединение.

(19) Согласен

я делаю по наименованию или коду.
Пр

Не оБъек.Код = ""

(21) иногда лучше молчать

(21) Тоже самое что и в (17) см (19).

(22) Да ладно, пусть высказывается. Только зачем? Ради флуда?
В (0) ТС всё правильно делает. ТОлько сама тема неясно за каким организована.

Неявное соединение лучше явного, улучшается читаемость кода.

(25) Автор, убей себя об стену.

(26) Сам убейся, он прав [в данном конкретном случае].
(23) то же самое, да да, кроме того что (21) грубо нерабочее.

(26) +1
Я не пойму - у автора именно битые ссылки или просто рлс работает?

(28) Да из обмена к нему хлам приехал.

(27) Никоим образом он не прав. Неявные соединения это ... чаще всего дикая беда.
Например, есть регистр накопления с кучей регистраторов.
Как думаешь к чему приведет код Регистратор.{чего-то там}?

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

(31) Ничего нового. Ответ очевиден

(32)не понимаю, к чему это относится, объясни

(17) как вариант, но в выборку будут попадать незаполненные значения полей составного типа...самым правильным вариантом будет:

ГДЕ Объект.РеквизитОбъекта ЕСТЬ NULL И Объект <> &ПустаяСсылкаНаОбъект

или

ГДЕ Объект.РеквизитОбъекта ЕСТЬ NULL И Объект <> Неопределено

(34) В обмене  и запросах поля составного типа = зло, ИМХо.

(35) Конечно зло, если не умеешь их готовить. По-мне лучше научится один раз и потом пользоваться, чем избегать постоянно.

(36) А тут далеко вообще не все умеют что-либо готовить.

(0)Код показывай

(30) Говорить любишь, думать нет.
Если поле не составное - нафиг не нужно явное соединение, достаточно обращения через точку [для данного конкретного, обозначенного в сабже случая].
Если поле составное и содержит пустую ссылку (неизвестного типа) - куда ты будешь соединять явно? Куда-нибудь? Таки придется делать все соединения вручную. Опять же нафиг не нужный лишний текст.
Повторюсь, (25) в значительной степени прав В ДАННОМ КОНКРЕТНОМ СЛУЧАЕ (капс для неумеющих читать с первого раза).
".Ссылка" в разы читабельней чем куча неужных соединений. В данной, блин, конректной, задаче.