то что во встроенном языке если первое условие верно дальше не идет я знаю . а как в запросе?
например:

истина
ложь
ложь
ложь
истина

вопрос всегда ли условие в запросе на первым условии удовлетвориться? или может последнею истину схватить?

В общем случае - это неопределено.

кто-нибудь понимает о чем ТС?

(2) Да

ИСТИНА ИЛИ ЛОЖЬ ИЛИ ЛОЖЬ ИЛИ ИСТИНА - до последней ИСТИНА будет проверять или на первой остановится

(1) то есть для запроса это правило не действует?

дык попробуй

(6) сейчас может сработать , а потом звезды не сойдутся (платформа поменяется) и будет попа

(4) До первой

(8) Я тоже где-то встречал, не помню где.

(5) да, не действует.
Ибо запрос - это декларативщина, а простой код - императивщина

(5) действует
если "ИЛИ" то до первой "ИСТИНА" результат "ИСТИНА"
если "И" то до первой "ЛОЖЬ" результат "ЛОЖЬ"

(11) код запроса по-другому исполняется нежели код языка 1с, запрос 1с по сути калькой переводиться в запрос скуля.

попробуй так Если Истина Или Объект.НесуществующийМетод()

во, короче )) v8: 8.2 логическое условие в запросе

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

вот ведь развели...
ВЫБРАТЬ
    ВЫБОР
        КОГДА ИСТИНА
                ИЛИ 1 / 0 = 0
            ТОГДА ИСТИНА
    КОНЕЦ КАК Поле1
возвращает истину

(16) а
ЫБРАТЬ
    ВЫБОР
        КОГДА ИСТИНА
                ИЛИ ЛОЖЬ
            ТОГДА ИСТИНА
    КОНЕЦ КАК Поле1

что вернет? :)

(17) ИСТИНА, вопрос не в этом ))

(17) тут можно и не смотреть - истину
в чем вопрос-то?

а какая вам разница? если бы в условии была функция, которая еще и данные меняла

а так - все равно

(20) Вот строишь запрос, в условие зная (16) ты будешь вначале менее ресурсоемкие отборы пихать, т.е. сначала простые, посложнее, в конце совсем сложные. Ну, к примеру.

(12) в общем случае будет проверять условия по порядку, но оптимизатор sql может изменить порядок проверки предикатов согласно плану выполнения запроса, если в условии сначала идет проверка на вхождение в выборку из вложенного запроса и потом простое логическое сравнение, то первым может провериться второе условие(более простое).

(21) на всех СУБД?

(23) В этом и вопрос - всегда ли? ))

+(22)
вот пример когда не по порядку, а по весу процессорного времени
ВЫБРАТЬ
    ВЫБОР
        КОГДА "АД0010325" В
                    (ВЫБРАТЬ
                        Справочник.Номенклатура.Код
                    ИЗ
                        Справочник.Номенклатура)
                ИЛИ 1 / 0 = 6
            ТОГДА "гуд"
        ИНАЧЕ "бед"
    КОНЕЦ КАК Поле1

В запросах хз как движок субд работает. Есть там стоимость вычисления, как то от этого еще зависит.

(0) Не надо тебе этого знать. Это как рассчитывать на одинаковый порядок записей при выборке без сортировки. Иначе будут неприятные сюрпризы.

(21) нафиг это не надо. отборы надо пихать что бы в индексы попадали, а не порядком их вычисления заботиться.

(25) Подтверждаю, на скуле ошибку выдает.

(29) Но по весу процессорного времени как раз и предлагается строить порядок ИЛИ в условии...