Доброго времени суток!

Просьба разъяснить, то ли что-то пропустил, то ли в настройки куда-то вынесли, но если есть в запросе такая конструкция


То при выполнении запроса не дает возможности прописать параметр. В колонке Type пишет NULL/NOT NULL, А в колонке Value контрола, куда заносить значение параметра, ничего нет, просто серое поле :(
Раньше конечно же работало, откатился вплоть до версии 2019.10.24.1 но не работает все равно. Поэтому и спрашиваю, может что-то в настройках, на первый взгляд не нашел.

Спасибо, это конечно как временное решение потянет, но не понимаю зачем было ломать, то что раньше работало. Да и не совсем логично, тип параметра определяется из типа поля, имя параметра то же самое. Не понимаю.
В тройке точно не нужно кастовать параметр если он определяет по типу поля в запросе. Это какой-то "волюнтаризм" :))
По крайне мере в стандарте SQL, по моему, такого требования нету.

Такой же как и первого и единственного (см имя параметра, они одинаковые), по типу поля.
Ты же "два параметра" схлопываешь в один, так зачем огород городить?
Саша, раньше таких заморочек не было и прекрасно все работало годами . Где в стандарте написано что в таком случае обязательно нужно кастовать параметр?

Саша, я это прекрасно знаю. ))
Ты не обратил внимание на Maxim Kovalenko "два параметра" схлопываешь в один
Ну если ты их по имени схлопываешь в один - ну подставь тип по полю, делов то. А самое главное, так работало годами и десятилетиями , если один и то же параметр, например код чего угодно, в каком-нибудь многоэтажном запросе присутствует много раз, мы по имени параметра его присваиваем один раз , а не 10. Ну давай будем логичны. В конце концов, если мы где-то накосячим, так пусть нам об это скажет сам сервер. Ты же почему-то за нас и за стандарт SQL( ибо ссылки на стандарт где бы это требовалось так и нету) решил что параметр обязательно нужно кастовать. Причем это нужно только для отладки , а сервер прекрасно это выполняет и без каста . Это хорошо если такой параметр в запросе один, а если это какой-то рабочий запрос из продакшена, где такой параметр может встречаться сильно больше одного раза?
Ну мы все твой продукт любим именно за дружественный и не перегруженный интрефейс и за гуманное отношение к нам) Ну так зачем осложнять нам жисть. Ну требовать он нас того, чего нету в стандарте - ну совсем не гуманно.
Я понимаю если бы всегда именно так и было (с кастованием) типа хорошо не жили, нефига и начинать :)
Но тут то, все великолепно работало, и на тебе. Наше же главное правило - "работает - не лезь" :))
Ну давай вернем как и былО?

Решил покапать. Забавно получается. У тебя тип параметра определяется по последнему вхождению в запрос параметра определенного имени.
Т.е. такая конструкция дает возможность завести данные


И без всякого каста, возможно ты просто поменял порядок перечисления параметров по имени, у которого брать тип.
Раньше было по первому вхождению, теперь по последнему.
Ну конечно, можно и поменять местами, в данном случае не велика работа, хотя помню, вроде как у Влада в презентации именно такой конструкции SQL значилось как сначала <имя поля> = параметр или параметр is null. Не берусь утверждать что порядок следования как-то регламентирован в стандарте, но то как отложилось, так и использовалось. Хотя, как мне кажется, именно первоначальный вариант where (field = :PARAM) or (:PARAM IS NULL) более логичен, Т.е. сначала определили тип по имени, дальше уже все остальные вхождения параметра с таким же именем не рассматриваем, ибо тип уже известен. Да и я слабо представляю себе, что бы разные типы параметров называли одним именем, это по любому получим ошибку от сервера о несоответствии типов. Да даже один тип параметра, но разная длинна строки вызовет ошибку сервера.
Т.е. определение типа по первому вхождению параметра с определенным именем более логична.

Саша, вообще-то про десятилетия фраза звучала так:
Maxim KovalenkoНу если ты их по имени схлопываешь в один - ну подставь тип по полю, делов то. А самое главное, так работало годами и десятилетиями
Ты же выдергиваешь из контекста. Речь шла о Maxim Kovalenkoесли один и то же параметр, например код чего угодно, в каком-нибудь многоэтажном запросе присутствует много раз, мы по имени параметра его присваиваем один раз , а не 10. Ну давай будем логичныТак что никакой фантазии по поводу десятилетий нету.
IBExpertИ нет, я не буду телепатически выяснять, какой из двух-трех-четырех-...-десяти типов куда подставить.
Не надо телепатически, все было описано предельно ясно и понятно. см мои два предпоследних сообщения. Если что-то не достаточно понятно описал, всегда готов уточнить, вообще не вопрос.
Я понял, настроения или желания вчитываться в то что тебе написали - нету. Пока одни эмоции. Ну сорри что потревожил.:)

Саша, приведенный пример вообще никак не подходит для описания текущей проблемы, два разных параметра с разными именами Один __vv_0 , второй __testID_1 Естественно и обрабатываются по разному. Я же тебе говорю о другой конструкции, когда имя параметра одно, но в тексте запроса присутствует много раз (where (field = :PARAM) or (:PARAM IS NULL) это как частный случай). Ты же мне все пытаешься привести пример как обрабатывается одиночный параметр типа SQL_NULL Еще раз, у тебя все параметры, присутствующие в запросе, одного имени, сворачиваются до одного параметра, хоть их там 10 штук в тексте. Понятно что для сервера это 10 параметров, но мы то присваиваем этот параметр по имени один раз, ровно то что я тебе и писАл. И все мои объяснения относятся именно к такой ситуации.
И то что у тебя тип параметра стал определяться по последнему вхождению в запрос, а раньше определялся по первом, это я тебе то же написал. Вот тебе еще пара картинок, которые подтверждают мои слова про определения типа параметра по последнему вхождению параметра в запрос. И заметь, никакого NULL. Вот о чем я говорю.

Ну, это взаимно, всегда пожалуйста:)

IBExpertВыложить тебе версию двухлетней давности, чтобы ты убедился? У меня их есть.

Ну, у меня их то же есть, поставил версию от января 2018 - там да, параметр который идет в конструкции (field = :PARAM) or (:PARAM IS NULL) назначается нормально. Теперь понятно, при схлопывании по имени, он у тебя просто игнорировался.

IBExpertТак что нефиг заниматься фигней, а нужно давать параметрам разные имена в таких случаях, вот и все.

Саша, почему ты считаешь что это фигня? Отнюдь. Я тебе больше скажу, именно твое предложение - фигня. Ибо выражение (field = :PARAM) or (:PARAM IS NULL) и делалось специально, что бы через один параметр получать либо один элемент списка или весь список. Так что тут параметр просто таки должен называться одним именем, иначе никакого выигрыша не получить.

IBExpertТеоретически, встретив параметр типа SQL_NULL, можно посмотреть, есть ли еще параметр с таким именем. И если есть, проигнорировать его как раньше. Тогда, по идее, должно работать "как раньше". Но фиг знает, насколько это правильно.

Ну вот, это ровно то, о чем я писАл несколькими постами выше. И если так сделать, то это будет как минимум логично. И наша благодарность не будет знать границ в разумных приделах :) . А то что это будет работать и без эксперта, так оно и так работает у всех кто использует такую конструкцию. Параметры то назначаются по имени, в подавляющем большинстве случаев. Так что будет работать. Собственно оно у тебя и работало в тех, старых версиях. Отлаживалось в эксперте, а потом переносилось в продакшен и прекрасно работает и по сей день. Так что пожалуйста, "не будет ли любезен многоуважаемый джин" ©Мюнхаузен именно так и реализовать работу с данной конструкцией?
Заранее спасибо!

Еще раз, это не моя реализация, это реализация сделана в сервере и именно в том виде в котором я её приводил.

В релиз ноте к 2.5. все это описано

Поддержка нетипизированных параметров в
предикате IS NULL
Адриано дос Сантос Фернандес
Ссылка в трекере: ( CORE-2298 )
По многочисленным просьбам (в частности, от программистов, использующих Delphi) добавлена воз-
можность использовать «один и тот же» параметр как условие фильтра по полю таблицы и проверять
его (параметр) на равенство NULL. Это позволяет разработчикам клиентских приложений (использую-
щим Delphi и другие языки программирования) использовать «отключаемые фильтры» (т.е. условия с
использованием параметров, которые «отключаются» присвоением параметру NULL), т.е. использовать
запросы следующего типа: WHERE col1 = :param1 OR :param1 IS NULL и далее по тексту.

Так что ничего я не экономил, а делал согласно документации.

Ну, цитата моя, и? Если придираться, то стилистически можно и получше было написать:), но суть не меняется. Такая конструкция имеет место быть, без всяких кастов и "возможностью использовать один и тот же параметр" Соответственно очень хочется поддержки в эксперте.

Во, совсем другое дело! Все работает.)))

P.S. Куда слать на пиво?))

Ну сорри, не думал что эта конструкция не известна.


Ну ровно то что релиз ноте и написано. Если я правильно понял твой вопрос.
использовать «отключаемые фильтры» (т.е. условия с
использованием параметров, которые «отключаются» присвоением параметру NULL),
На самом деле это только так кажется, что ну подумаешь, одна или 2 строки задачи параметра. Просто в реальных запросах параметров много, в том числе и конструкций такого типа, и на круг получается уже прилично, да и читаемость кода снижается.