Есть обработка, по которой нужно найти некоторые значения, в ней есть варианты поиска. Вот запрос:

```1c
    Запрос.Текст =
    "ВЫБРАТЬ
    | ЗаказПокупателяТовары.Ссылка.Ссылка КАК Заказ,
    | ЗаказПокупателяТовары.Ссылка.Дата,
    | ЗаказПокупателяТовары.Ссылка.Контрагент КАК Клиент,
    | ЗаказПокупателяТовары.Номенклатура
    |ИЗ
    | Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
    |ГДЕ
    | ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент
    | И ЗаказПокупателяТовары.Номенклатура.Ссылка = &Товар
    | И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА";

    Запрос.УстановитьПараметр("Клиент", Клиент);
    Запрос.УстановитьПараметр("Товар", Товар);
    Запрос.УстановитьПараметр("Проведен", Истина);
```

Как сделать, чтобы запрос отрабатывал, когда заполнен один из Параметров. УТ 10.4 форма обычная.
---
Во-первых научитесь отлаживать запросы через консоль запросов.
А во-вторых вот пример когда заполнен либо товар либо клиент

```1c
    ВЫБРАТЬ
    ЗаказПокупателяТовары.Ссылка КАК Заказ,
    ЗаказПокупателяТовары.Ссылка.Дата,
    ЗаказПокупателяТовары.Ссылка.Контрагент КАК Клиент,
    ЗаказПокупателяТовары.Номенклатура
    ИЗ
    Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
    ГДЕ
    ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент
    И Выбор когда &Товар = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Номенклатура= &Товар Конец
    И Выбор когда &Клиент=ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Ссылка.Контрагент = &Клиент Конец
    И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
```
---
Зачем так сложно?

```1c
    ГДЕ
    &Товар В (ЗаказПокупателяТовары.Номенклатура, ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка))
    И &Клиент В (ЗаказПокупателяТовары.Ссылка.Контрагент, ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка))
    И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
```
---
пример обработки
---
в запросе, в условие проверять параметр на пустую ссылку
Выбор когда &Товар = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) тогда истина иначе ЗаказПокупателяТовары.Номенклатура.Ссылка = &Товар
Конец
---
очень плохое условие и написано ужасно
---
а в чем ужос?
---
во-первых, ЗаказПокупателяТовары.Номенклатура.Ссылка.
Во-вторых, любые вычисления полей а) дополнительная нагрузка на СУБД, причем абсолютно ненужная б) дает возможность оптимизатору запросов сойти с ума и выдать кривой план запроса, при этом в индекс 100% такие конструкции не попадают, что приведет к ненужному сканированию всех таблиц табличной части документа.
Погуглите про SARG предикаты в SQL
---
вы не по адресу - запрос писал не я а топикстартер, я лишь предложил проверять пустой параметр в самом запросе. Подмена текста запроса с проверкой заполненности параметров в конечном итоге лучше, то текста писать больше.
---
ужас как раз в таких проверках в самих запросах
---
С точки зрения максимальной масштабируемости - да, ужас.
А на практике использование динамического запроса для решения этой задачи я бы назвал преждевременной оптимизацией в большинстве случаев.
---
можно ведь сразу писать правильно, чтобы в один момент запрос колом не встал. Особенно, если нет возможности обновить оперативно.
---
1 Зачем ?
 во-первых, ЗаказПокупателяТовары.Номенклатура.Ссылка.
Поясните вашу мысль?
ЗаказПокупателяТовары.Номенклатура - это уже ссылка.....

2. тут с вами согласен... Повелся на краткость текста от (3)...
Изначально предлагал ОБЪЕДИНИТЬ ВСЕ в запросе (для консоли запросов, если не использовать возможность обработок менять текст запроса )
---
ЗаказПокупателяТовары.Номенклатура.Ссылка.
Это я перепечатал и указал, что Ссылка.Ссылка - плохо

Если объединить все, то логика запроса сломается. Достаточно просто собрать запрос. Кстати, с 8.3.9 запрос имеет объектную сущность - схема запроса. Не пробовал, но можно по отзывам знакомых, вещь классная
---
Ясно...
Конечно идеально менять текст запроса в зависимости от настроек формы.....
Это просто и эффективно...
---
Сообщение было скрыто модератором.
---
4 - зачем так сложно? а если параметров штук 5 будете 5 раз объединять все?
---
Я уже согласился с вами!
---
см (12)
---
Во-первых научитесь отлаживать запросы через консоль запросов.
А во-вторых вот пример когда заполнен либо товар либо клиент

```1c
    ВЫБРАТЬ
    ЗаказПокупателяТовары.Ссылка КАК Заказ,
    ЗаказПокупателяТовары.Ссылка.Дата,
    ЗаказПокупателяТовары.Ссылка.Контрагент КАК Клиент,
    ЗаказПокупателяТовары.Номенклатура
    ИЗ
    Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
    ГДЕ
    ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент
    И Выбор когда &Товар = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Номенклатура= &Товар Конец
    И Выбор когда &Клиент=ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Ссылка.Контрагент = &Клиент Конец
    И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
```
---
см (12)
---
Зачем так сложно?

```1c
    ГДЕ
    &Товар В (ЗаказПокупателяТовары.Номенклатура, ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка))
    И &Клиент В (ЗаказПокупателяТовары.Ссылка.Контрагент, ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка))
    И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
```
---
не все, что просто - правильно
Специально попробовал Ваш способ. Все поля в условии проиндексированы.
Index scan говорит о том, что был полностью просмотрен некластерный индекс.

Попробуйте на досуге , например,

```1c
    ВЫБРАТЬ
    ЗаказКлиента.Ссылка,
    ЗаказКлиента.Дата
    ИЗ
    Документ.ЗаказКлиента КАК ЗаказКлиента
    ГДЕ
```

а)

```1c
    &Дата В (ЗаказКлиента.Дата, ДАТАВРЕМЯ(1, 1, 1))
```

б)
```1c
    ЗаказКлиента.Дата = &Дата
```
---
Я не спорю, что если условие в запросе не нужно, то лучше его не вставлять.
Но вариант с проверкой параметра В работает лучше и выглядит / читается лучше чем через ИЛИ и Выбор.
---
на самом деле Ваш вариант работает так же, как через Выбор. Пример, я привел выше, чем чреваты такие конструкции. Представьте себе, если нужно отсканировать не тысячу, а миллион записей, десятки, сотни, а то и миллиард. Можно и не дождаться выполнения запроса
---
"В" работает лучше чем "ИЛИ", читается лучше чем Выбор))

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

Да это понятно.
Но кажется у ТС нет такой проблемы.
В случае, если записей будут миллионы и более, проблемы будут совсем другие.
Запрос можно не дождаться даже если будет просто выборка без отборов, потому что результат будет очень большой.
---
ВЫБРАТЬ
ЗаказПокупателяТовары.Ссылка КАК Заказ,
ЗаказПокупателяТовары.Ссылка.Дата,
ЗаказПокупателяТовары.Ссылка.Контрагент КАК Клиент,
ЗаказПокупателяТовары.Номенклатура
ИЗ
Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
ГДЕ
ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент
И Выбор когда &Товар = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Номенклатура= &Товар Конец
И Выбор когда &Клиент=ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка) тогда Истина иначе ЗаказПокупателяТовары.Ссылка.Контрагент = &Клиент Конец
И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
(6)
(6)
---
консолью пользоваться умею, но была проблема в написании условия.
По вашему примеру все получилось.спасибо
---
Извините, страница обновляется криво, не увидел
---
1. Зачем

| ЗаказПокупателяТовары.Ссылка.Ссылка КАК Заказ,

|ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент
| И ЗаказПокупателяТовары.Номенклатура.Ссылка = &Товар
???

Можно ведь

```1c
    ЗаказПокупателяТовары.Ссылка.Контрагент= &Клиент
    | И ЗаказПокупателяТовары.Номенклатура= &Товар
```

2. Если Вы выбираете данные запросом без СКД, то в данном случае лучше собрать запрос
|ГДЕ ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА";

Если ЗначениеЗаполнено(Клиент) Тогда

```1c
    Запрос.Текст = Запрос.Текст + "
    | ЗаказПокупателяТовары.Ссылка.Контрагент.Ссылка = &Клиент";
    ...+...
```
---
```1c
    |ВЫБРАТЬ
    |ЗаказПокупателяТовары.Ссылка КАК Заказ,
    |ЗаказПокупателяТовары.Ссылка.Дата,
    |ЗаказПокупателяТовары.Ссылка.Контрагент КАК Клиент,
    |ЗаказПокупателяТовары.Номенклатура
    |ИЗ
    |Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
    |ГДЕ
    |истина
    |"+?(ЗначениеЗаполнено(Клиент)," И ЗаказПокупателяТовары.Ссылка.Контрагент= &Клиент", ")+"
    |"+?(ЗначениеЗаполнено(Товар)," И ЗаказПокупателяТовары.Номенклатура = &Номенклатура", ")+"
    |И ЗаказПокупателяТовары.Ссылка.Проведен = ИСТИНА
```

Лучше так делать если у вас реквизиты составного типа
---
чем лучше?
---
Программная замена текста запроса, с точки зрения отладки - уже плохо! Так придем (да уже пришли) в кодам ЗУП, где запросы на 10 страниц, собранные кусками... в конструкторе не открыть, без конструктора не осилить. Так что вопрос оптимизации запроса на одних весах с реализацией отладки того-же кода...
---
Вы живете в мире, в котором ресурсы серверов бесконечные и удобство отладки важнее, чем хорошо оптимизированная система, которая будет работать всегда.
Учитесь читать запросы без конструктора
---
я живу в нашем мире, давайте тогда уже писать на ассемблере, я умею, если есть среда разработки она должна себя отрабатывать и не заставлять извращаться.... Вы прочитаете 10-и страничный код запроса, дополняемый кусками текста, и сможете внести коррективы??? Сниму шляпу!
---
Не поверите, но периодически приходится писать простыню запроса, а через какое то время резать на куски, и уже что-то добавлять, что- то убирать, где-то менять логику. Понятно, что трудозатраты на отладку возрастают, но зато система чувствует себя хорошо, ресурсов лишних не потребляется, DBA не ругается, а пользователи получают результат за секунды, в некоторых случаях за минуты, а запускают отчет или механизм и уходят домой.
Для отладки конечно приходится собирать запрос по кускам в консоли, чтобы проверить, а потом вычленять куски из консоли
---
Вы живете в мире, в котором ресурсы серверов бесконечные и удобство отладки важнее, чем хорошо оптимизированная система, которая будет работать всегда.
Да, мы живем в мире, где ресурсы серверов постоянно дешевеют а труд программистов дорожает. А бизнес-требования зачастую очень динамичны, что повышает стоимость оптимизаций и уменьшает пользу от них. Поэтому да - удобство отладки и сопровождения ценится очень высоко в бизнес-софте, в котором хорошо оптимизированные системы редко сильно выгоднее систем с "достаточной производительностью". Это не призыв писать говнокод. Но и упирать на идеальный план выполнения каждого запроса за счет ухудшения его поддержки из расчета на то, что это окупится ЕСЛИ и КОГДА объем данных вырастет до соответствующих величин - явная преждевременная оптимизация, если это не критичный по нагрузке участок.
ЗЫ. Ессно какие-то границы должны быть даже при прототипировании. Как минимум производительность не должна стоять в явной пропорции с обычным накоплением документооборота с течением времени.
---
напишите это Сергею Носкову из BIA или Олегу Репникову из Вымпелкома.
Сервера и СХД дешевеют не так быстро, как Вам кажется. Я думаю, что нам с Вами спор даже затевать не стоит, мы просто в пустую потратим время. Я много видел баз, в которых программисты считали, что главное-отладка, видел, где главное-скорость и нагрузка. Так вот, с первыми в 99% работали недоучки, которые проектируют систему тяп-ляп и в продакшен, вторые же каждую мелочь продумывают заранее. В том числе и динамично изменяющуюся архитектуру бизнес-решения и хотелки пользователей.
Просто даже на небольших базах нужно приучаться писать оптимальный код, который не будет генерить технологический долг.
П.С. Писать красивый, понятный и оптимальный код - настоящее искусство, в котором скорость разработки, высокая скорость выполнения и оптимальная нагрузка на железо сочетаются в квалифицированном разработчике. Конечно, много индусов, которые по разным причинам пишут как попало, начиная от наседания бизнеса, что надо было еще вчера, заканчивая банальной ленью. Вот поэтому бизнес и готов платить много программисту, а не плодить штат недоучек, которые сделают быстро и дешево.
---
мы просто в пустую потратим время
Именно так. Потому что найти правильный баланс в понимании, когда стоит стелить соломку уже сейчас исходя из цена/эффект этих работ, а где не стоит пока на это заморачиваться - в самом деле настоящее искусство и продукт большого опыта.
Но естественно, чем программист опытнее и продуктивнее, тем качественнее он сделает изначальный продукт, даже если это прототип - тут даже спорить не о чем.
ЗЫ. Мы с вами зацепились за случай, когда "оптимальность" идет в ущерб "красивости и понятности". То есть когда уже начинается trade-off. А следовательно, однозначного мнения тут быть не может. Потому что оценка "оптимальности" тоже сильно зависит от контекста. "Оптимальный" <> "Максимально производительный"
---
Может кто еще подскажет как записать правильное условие для выбора нужных документы.
Есть док Отборочный в нем реквизит документ остнование =тип ссылка все документы.
Но мне нужно отобрать из найденных только 2.
мой запрос

```1c
    ВЫБРАТЬ
    | ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование КАК Заказ,
    | ОтборочныйЛистСерийныеНомера.Ссылка.Дата
    |ИЗ
    | Документ.ОтборочныйЛист.СерийныеНомера КАК ОтборочныйЛистСерийныеНомера
    |ГДЕ
    | ОтборочныйЛистСерийныеНомера.Серийный ПОДОБНО &СерийныйНомер
    | И ОтборочныйЛистСерийныеНомера.Ссылка.Проведен = ИСТИНА
    | И ОтборочныйЛистСерийныеНомера.Ссылка.Дата МЕЖДУ &ДатаС И &ДатаПо
    | И ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ЗаказПоставщику
    | И ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ВозвратТоваровПоставщику
```
---
ДокументОснование.Ссылка ССЫЛКА ... зачем вы везде добавляете .Ссылка?
---
не знаю.... и так и так не работает(
---
И ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ЗаказПоставщику
        | И ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ВозвратТоваровПоставщику
Такое условие никогда не выполнится.
Делайте Объединением с отдельными условиями.
---
С какими условиями?
пробовала найти только по одному документу делать отбор все равно ничего
---
С какими условиями?
ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ЗаказПоставщику
| И ОтборочныйЛистСерийныеНомера.Ссылка.ДокументОснование.Ссылка ССЫЛКА Документ.ВозвратТоваровПоставщику

Это два взаимоисключающие условия. Не может быть один и тот же документ и ЗаказПоставщика и ВозвратТоваровПоставщику.
Тут нужно использовать ИЛИ. Но ИЛИ не рекомендуется и вместо него предлагается использовать объединение запросов, разбив отбор по типам документов.

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

Еще вот такая конструкция: "ОтборочныйЛистСерийныеНомера.Серийный ПОДОБНО &СерийныйНомер" зачем?
Поиск по неполному соответствию? А в конце строки поиска знак % указан? Без него будет равносильно просто "ОтборочныйЛистСерийныеНомера.Серийный = &СерийныйНомер".
---
Еще вот такая конструкция: "ОтборочныйЛистСерийныеНомера.Серийный ПОДОБНО &СерийныйНомер" зачем?
Поиск по неполному соответствию? А в конце строки поиска знак % указан? Без него будет равносильно просто "ОтборочныйЛистСерийныеНомера.Серийный = &СерийныйНомер"

Только так отрабатывает запрос и знака % нет. Зато работает
---
Только так отрабатывает запрос и знака % нет. Зато работает
Так работает или нет?
Без подстановочного знака (% означает любое количество любых символов) будет искать только по точному соответствию. Т.е. если есть Серийник "0000123", то по "123" не найдет. Тут нужен подстановочный символ спереди.
Для варианта: "123 " не найдет по "123". Тут нужен подстановочный символ в конце.
---
там как раз нужно точное совпадение

и большое спасибо за подсказку с объединением запросов, в консоли все сработало!