есть строчка из запроса:
И (ВидПлатежа = &ВидПлатежа или &ВидЗаполнения = Истина)) КАК ПлатежиОстатки

вопрос: почему когда я передаю в ВидЗаполнения значение Истина, запрос все еще обращает внимание на условие ВидПлатежа = &ВидПлатежа?

потому что оно первое

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

(16) что значит обращает внимание?

Условие считается слева направо

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

(4) и ЧО?

2(5) э... и что?
Я имею в виду что при исполнении кода в8 не будет проверять все условие до конца, если на каком-то этапе уже гарантировано будет истина или ложь. а в языке запросов - может и будет - мне например неизвестно...
Это все равно как в коде можно сравнить с NULL, а в языке запросв - нельзя

(6) И всйо!

2(6) например в семерке вот такая конструкция приводила к ошибке:
Если Истина Или Объект.НесуществующийМетод()
а в в8 - прокатит...

(0) а что значит "все еще обращает внимание"?

(8)(9) хватит бухать на работе!
это пример из текста запроса!

(10) вот и я в (3) спросил

(11) И? чО спросить-то хотел?

2(11) так и скажи - что в запросе булево выражение будет вычисленно до конца.

(13) да я собственно призвал, а не спросил
короче твое "Условие считается слева направо" вряд ли автору поможет

и объяснил бы почему.

(12) значит, что даже если ВидЗаполнения = Истина, запрос проверяет совпадение ВидПлатежа... а надо что бы не проверял...

(7) Это все равно как в коде можно сравнить с NULL, а в языке запросв - нельзя

ВЫБРАТЬ
   ВТ.ДоговорКонтрагента
ИЗ
   ВТ КАК ВТ
ГДЕ
   ВТ.Проект ЕСТЬ NULL

работающий запрос, или ты не про это?

(14) а ты интересно как это сможешь определить до конца или нет? в запросе (1С) методов нет, чтобы проверить это

2(19) я в 9 написал метод. Легко можно проверить

(17) пишите другой текст запроса.

(20) в языке запроса, ога

2(22) капец, чувак... ты фонтазию свою скурил что ли?
Если Истина ИЛИ ССылка.НесуществующийРекизит

Напиши строку полностью что ли, ну и может стоит скобки поставить:
( .... И ((ВидПлатежа = &ВидПлатежа) или &ВидЗаполнения)) КАК ПлатежиОстатки

(23) ну и как ты, чувачок, проверишь проверяет он второе условие или нет?

кстати в (0) вообще кусок не рабочий, имхо

(23) хотя для составных типов, этож буде NULL (гыгыгыгы)
тогда обязан проверить

я проверил.

вот такой запрос:

ВЫБРАТЬ
   Банки.Ссылка
ИЗ
   Справочник.Банки КАК Банки
ГДЕ
   ИСТИНА Или &Параметр

выдаст результат при значении Параметр равное лжи, значит в запросе тоже логическое выражение вычисляется не до конца

(25) Код не рабочий, но и критических ощибок он не выдает...
кстати я вот тут недельку назад писал условие вот так вот:
   И (ЦветомодельКоллекционныеАтрибуты.Поставщик.ПоставщикКоммерческий = &Поставщик ИЛИ &ПоставщикЗаполнен = 0)

и оно нормально отрабатывало...

еще вопросы? :)

(28) что значит нормально?

нет, фигня

ничего не доказывает

(27) с чего бы вдруг не до конца? =)

(27) вывод не верный потому что "Истина или Ложь" дает "Истина"

(32) передай туда NULL

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

ВЫБРАТЬ
   Банки.Ссылка
ИЗ
   Справочник.Банки КАК Банки
ГДЕ
   ИСТИНА Или &Параметр

Где Параметр я устанавливаю Дате - выдает ошибку

Текст запроса: Строка 6: {(6,8)}: Неверные параметры "ИЛИ"
ИЛИ <<?>>&Параметр)

Тоже самое:

ВЫБРАТЬ
   Банки.Ссылка
ИЗ
   Справочник.Банки КАК Банки
ГДЕ
   ИСТИНА Или Банки.НесуществующееПоле


Текст запроса: Строка 6: {(6,19)}: Поле не найдено "Банки.НесуществующееПоле"
ИСТИНА Или Банки.<<?>>НесуществующееПоле


====

(0)Чувак, переписывай запрос

(36) Не факт. Параметры могут заранее проверяться.
Короче, фиг проверишь. Вообще, подозреваю что метод вычисления логических выражений может быть вообще опциональным на серваке SQL

И эти люди ратуют за советское образование

(37) Это тоже ничего не доказывает.

если телепатировать, наверняка у него ВидПлатежа NULL.

(38) скулю пойдет весь запрос, 1ска вырезать ничего не будет..

В тоже время в коде:

http://screencast.com/t/8gJDklqpX4

(42) Кэп? Речь о том, как скуль будет считать.

2(42) если пропустит его предварительно

(43) сравнил теплое и мягкое =)

2(40) в свете (43) имеем явное различие между тем что делается в коде и в запросе.

2(46) Ну, в этом и был пойнт.

(43) хаха, если 1С ЭТО вычисляет, то она шляпа

2(49) Это рекламировалось как огромный шаг в перед по сравнению с 77 еще как только 8.0 вышла.

(47) Разве что. Не слишком ценная информация, поскольку и так ясно что запрос выполняет сиквел, а код 1С - сама 1С.

и по сути в (0) об этом и вопрос. Теперь мы знаем что для запросов это не работает.

(50) А это разве не так? Избавляет от вложенных условий не в ущерб быстродействию.

2(51) Все верно, но прежде чем СКЛ получит свой текст запроса, 1С должна будет транслировать Банки.НесуществующееПоле в СКЛ-представление. Сделать этого не может. И поэтому понятно, почему она в случае языка запросов вычисляет логчиские выражения до конца, а не как в коде - чтобы СКЛ не сошел с ума.

(44) судя по планам - если первое условие истина - то второе игнорирует.

(50) это имеет право на жизнь, только по причине нетипизированности 1С
вообще весь плюс тут когда используются именно методы или обращения по ссылкам к базе:

Если МетодА() или МетодБ() Тогда

2(53) этот вопрос я переадресую (49), потому что мне по правде все равно. :) Главное чтобы я это знал и мог использовать.

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

(55) судя по планам также можно сделать вывод, что оптимизатор увидев заранее истинное условие: "Истина или А" просто выплюнул это условие вообще

(58) думаю это можно почитать в доке к окнкретной СУБД. :)

(53)+ если задана константа в первом условии. если зависит от поля таблицы - то вычисляться будут оба каждый раз..

(54) Да ничего она (1С) не вычисляет. Не путай синтаксическую проверку запроса с его выполнением. Вычисляет она в файловой версии.

(60) Скорее всего. И скорее всего это опционально. Помню, в настройках компиляторов тоже можно было выбирать, какой метод вычисления логических выражений использовать.

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

Зависит от оператора сравнения:
http://screencast.com/t/eLMAcbAW3

(64) ну если оба условия не только вычисляют что-то, но и изменяют состояние
хотя имхо плохой код это

(65) потому что сначала выполняется ИЛИ, а потом И

(64) еще 1С такой скрин и еще больше буду ненавидеть 1С, за

А = Истина или Перечисления.СтавкиНДС.НДС18;
Сообщить(А); //выдает Истина

))

еще:
http://screencast.com/t/17mZU22p6b

(69) ответ в (67)

2(70)я ничего не спрашиваю. :) попробуй просветить кого-то другого. :)

2(62) да, наверное ты прав... Тут до вычислений вообще не доходит.

(68) Считает абсолютно правильно. Просто в идеале при синтаксической проверке модуля должно ругаться.

(49) а что собственно не так?

(74) NULL<>НЕОПРЕДЕЛЕНО

(75) а она говорит что NULL=НЕОПРЕДЕЛЕНО ?

(76) я говорю, а 1С меня не понимает, НЕНАВИЖУ!

2(77) :)
http://screencast.com/t/FfuJ835q3MV4

(78) сукин сын!!!

(78) вообще NULL <> NULL если что =) так что шляпа!

Это стёб, или кому-то до сих пор что-то с NULL непонятно?

(81) NULL = NULL - Ложь по определению =) а в 1с - Истина =)

2(82) В запросах - Ложь, в коде - истина...

(83) и как можно сравнить ничто с ничтом? =)

http://screencast.com/t/PTQntUxT1mVO

(82) А... Есть такой ньюанс :)
Но он логичен и объясним. В языке запросов - всё канонично. Для логических операций с NULL есть специальный оператор.
Но во внутреннем языке выборку тоже нужно как-то анализировать? Решили не заморачиваться с новыми операторами и заставить работать стандартные :) Ибо в этот момент финты ушами с NULL в SQL уже теряют смысл. Вполне логичный ход.

2(84) без понятия, меня это не касается...