надеюсь ла здесь по теме. Проблема такая:
у меня ошибка если я пытаюсь протолкнуть следуещеe
SELECT COUNT(id) FROM dbo.mf_type WHERE ... AND case
when text_value is null and @text_value is null then true
when text_value is null and @text_value is not null then false
when text_value is not null and @text_value is null then false
when text_value <> @text_value then false
when text_value = @text_value then true
end
AND
...
алтернативой может быть ISNULL() но ето не подходит.
есть у кого нибудь какие нибудь предложения?

э-э-э-э.... ну, во-1-х, в сиквеле (как минимум до версии 2000 вкл.) нет логического типа данных. Так что конструкции с true и false не катят. Поэтому, если уж так приспичило, ставь вместо true и false числа 1 и 0 соответственно, а после case'овского end'а добавь сравнение с единицей, т.е. = 1.
Во-2-х, а почему бы не заменить этот страшный case простейшим выражением типа:
WHERE ... AND ISNULL(text_value,'') = ISNULL(@text_value,'') AND ...
по логике вроде то же самое получается
--------------
Авиатор х#ев

обошел с другой стороны
isnull() не подошел бы тогда '' = null, а ето не совсем одно и тоже
Всеровно спасибо

да, эту деталь я пропустил :)
--------------
Авиатор х#ев

Долго считаться будет.
Сделай проверку:
If IsNull(@text_value) Then... и три разных подзапорса.
Не помню как в MS SQL, но в общем случае нет гарантии на то,
что проверка в CASE будет производится в порядке написания.
Т.е.
when text_value <> @text_value then false
when text_value = @text_value then true
могут давать фаулт при NULL.

э-э-э-э-э...
If IsNull(@text_value) Then...
не катит. Синтаксис ISNULL'а в сиквеле именно такой, какой я привел, а не VB'шный, как у тебя. Если так делать, то надо IF @text_value IS NULL. И еще: THEN в таких конструкциях в T-SQL не употребляется. Как в C
Не помню как в MS SQL, но в общем случае нет гарантии на то,
что проверка в CASE будет производится в порядке написания.
в сиквеле она (эта гарантия) есть. Это документировано.
--------------
Авиатор х#ев

Я, вообще-то об TSQL думал.
Давно не пишу сложности вне процедур.

declare @text_value varchar(20)
set @text_value = ''
--set @text_value = null
SELECT COUNT(ID) FROM dbo.mf_type
WHERE apstatus = 'Passiv' AND
SpalteName =
case
when text_value is null and @text_value is null then 1
when text_value is null and @text_value is not null then 0
when text_value is not null and @text_value is null then 0
when text_value <> @text_value then 0
when text_value = @text_value then 1
end
Tablichka tvoja dolgna SpalteName imet' (int ili bit)

Я, вообще-то об TSQL думал.
ну а я о ком разоряюсь?
--------------
Авиатор х#ев

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

SELECT COUNT(id) FROM dbo.mf_type WHERE ... AND
(text_value = @text_value Or (text_value is NULL And @text_value Is NULL))
AND
...
А так чего нельзя?

так тоже можно... компактно... хотя это немножко уже игры с огнем, имхо. Если вдруг где-то понадобится аналогичная конструкция, но в инвертированном виде, то нужно быть очень внимательным: перед синей частью (в отличие от авторской конструкции с CASE) НЕЛЬЗЯ будет просто взять и поставить NOT. Т.е., поставить-то, конечно, можно, но вернет неправильные результаты.
--------------
Авиатор х#ев

In der Kürze liegt die Würze

А добавить скобки?
А вообще - длинные вычисления условий в SQL - мрак. если совсем
критично, то наверное легче сделать временную табличку и пользовать
стандартный Join.

скобки не спасут. Дело в том, что неявная булева логика в условиях с NULL не двузначна, а 3-х-значна. Существует там такое условное значение UNKNOWN, наряду с условными TRUE и FALSE. Этот UNKNOWN возникает при сравнении какого-то значения с NULL'ом. В общем-то, ничего страшного, т.к. когда этот UNKNOWN возникает где-то при вычислении в условияи WHERE, он, в общем-то, очень похож на FALSE. И ведет себя "хорошо", если его OR'ить или AND'ить с другими логическими выражениями в WHERE. Но есть 1 закавыка: при применении NOT к UNKNOWN'у получается опять же UNKNOWN. Это как раз и будет в том примере, если влепить туда NOT. И это исказит всю логику. Поэтому я и написал, что нужно быть очень осторожным при дальнейших модификациях этого кода. Впрочем, это все уже дебри.
А вообще - длинные вычисления условий в SQL - мрак. если совсем
критично, то наверное легче сделать временную табличку и пользовать
стандартный Join
ну-у-у... it depends... порой и можно более-менее серьезные вещи вылепить. Но... скажем, для репортинга - до поры до времени можно обходиться вьюхами, но потом, когда возникает потребность в сложных вычислениях по всяким бл#%ским квартальным отчетностям, то тут уже действительно надо строгать серьезные хранимые процедуры. А там уже и временные таблички, и табличные переменные, и прочий арсенал.
--------------
Авиатор х#ев

Там вроде двойное условие исключающее UNCNOWN.
Это не "нуууу", это я так с Аксессом борюсь. Мне вот нужно было сделать
экспорт булевых значений. Там они Yes/No, а на выходе надо было иметь
текст true/false. Покарячился с условиями с полчасика, полюнул, вбил
двустрочную таблицу и не знаю проблем... Заодно подстраховался на
тот случай, что потребуется не true/false, а Да/Нет
Да, вспомнилось старое правило - данные должны быть в таблицах, а логика
- в коде, и не дай бог перепутать или смешать.
Вьюхами практически не пользуюсь - базовая установка: важна - не база,
важен - скрипт. А поддерживать скрипты, распиханные по разным местам
- я не самоубийца. Так что изначально - определение интерфейса
в виде процедур и имплементация - скрипт с процедурами...

Там вроде двойное условие исключающее UNCNOWN.
UNKNOWN вылезает моментально в 1-м сравнении, когда кто-то из двоих NULL. Я седня днем даже примерчик состряпал, чтобы убедиться, что поставленный впереди NOT все курочит ;)
с Аксессом
свят-свят, сгинь, нечистая
в коде, и не дай бог перепутать или смешать
приходилось пару раз грешить :/ и в ту, и в другую сторону. Табличная UDF, возвращающая набор "зашитых" констант. И SQL-стэйтменты, хранящиеся в таблице. Но это единичный случай. Какие-то мотивы были, но, как счас вижу, не особо важные. Со временем сама собой возникнет необходимость переделать.
Вьюхами практически не пользуюсь - базовая установка: важна - не база,
важен - скрипт. А поддерживать скрипты, распиханные по разным местам
- я не самоубийца.
ну и у меня тоже - важен скрипт. А вьюхи - его часть. Такой же равноправный код, как хранимки, функции и триггеры. Вьюхи хороши тем, что с ними удобно по уровням иерархию строить, конструирую все более сложные уровни сочетания базовых таблиц. Да и в нашем Crystal-репортинге они незаменимы. Есть набор вьюх - коллега сидит и кропает на их основе репорты. Складывает из вьюх источник данных, как из кубиков, соединяя их. А Crystal до 9-й версии ваще не умел хранимки с таблицами и другими хранимками склеивать. Да и в 9-й версии это не ахти какая производительная фича. А под каждый репорт я свою хранимку писать не могу - их 200 штук стандартных плюс еще по 50 под спец. нужды каждого клиента.
--------------
Авиатор х#ев

UNKNOWN вылезает моментально в 1-м сравнении, когда кто-то из двоих NULL.
-------------
Это решаемо - поменять местами операнд у OR.
свят-свят, сгинь, нечистая
-------------
А что делать? Железяка не тянет - лап-топ P3 с ХР - еле-еле сама дышит.
А руки все одно чего то делать хотят... Да и это... часть задач можно и
под ним пустить. Вот например - база выкладывается на вебе. Никакой
логики внутри - голые таблицы с принудительным полным обновлением
из... DBF'ов. Можно, конечно, MySQL, но потом зверя Юзверя надо сильно
дрессировать. А так - все путем - в Borlandэовском Билдере форма с
селектором диретктории с DBF'ами и кнопка Импорт.
Со временем сама собой возникнет необходимость переделать.
---------------
Рульный рулес, как показывает практика. Я разок тоже пихал куски SQL в
таблички... после 50 тыс стало тормозить...
Такой же равноправный код...
--------------
Не совсем. У меня есть правило.требование, чтобы при внесении изменений
в одну таблицу надо было делать изменения не более чем в одном файле
скрипта. Вьюшки это требование рушат напрочь...

Да и в нашем Crystal-репортинге они незаменимы.
А Crystal до 9-й версии ваще не умел хранимки с таблицами и другими
хранимками склеивать.
-------------
Ну это как посмотреть. Если что-то специфическое, то пусть оно и будет
комом-репортом. А сама база и ее логика - должны быть прозрачны.
По мне - так.
А под каждый репорт я свою хранимку писать не могу...
--------------
А я их пишу, точнее - генерю, по 4 штуки на каждую форму. Просто на
автопилоте по шаблону. Но это не репорты, это формы. Репорт последний
раз и не помню когда лепил.
плюс еще по 50 под спец. нужды каждого клиента.
---------------
А вынести в отдельную базу?

Это решаемо - поменять местами операнд у OR.
гм... я боюсь, что вычисления 2-го операнда при этом все равно не избежать. Да даже если и избежишь - опять же выходит, что нужно следить за порядком, т.е. нужна большая осторожность, о чем я уже и говорил.
А что делать?
да не, я просто подумал, что для меня, напр., было бы персональной трагедией переходить на Access после сиквела :))
чтобы при внесении изменений
в одну таблицу надо было делать изменения не более чем в одном файле
скрипта. Вьюшки это требование рушат напрочь..
репортинговые хранимки, использующие ту же туеву хучу столбцов, что и вьюхи, точно так же рушат это требование.
И еще насчет репортинга, поясню. При большом количестве репортов самый простой способ - это сделать грамотную иерархию вьюх-кубиков, которые разработчики репортов будут использовать как конструктор, комбинируя их в различных вариантах. Покрывать каждую комбинацию своей хранимкой - дело безнадежное. И даже какие-то спец. репорты для особых клиентских нужд в большинстве своем покрываются комбинацией уже существующих вьюх.
В общем, в нашем случае этот подход себя более чем оправдывает.
--------------
Авиатор х#ев

я боюсь, что вычисления 2-го операнда
----------------
Теория говорит, что должно иметь место Отсечение...
Ну разве что дядя Билли, за то мы все его и любим, думает по-другому...
было бы персональной трагедией переходить на Access после сиквела :))
---------------
Для меня не сильно критично и даже кое-что делать в нем удобнее.
Например, лепить таблицы и структуру - в ЕМ мне не так удобно. А вот
лепить всю аппликцию в нем - это да, это полная труба.
самый простой способ - это сделать грамотную иерархию вьюх-кубиков
---------------
Угу... А потом придет кто-то умный и попросит добавить столбец в таблицу.
У меня такое - регулярно. Консультанты понимают в том, что и как надо
считать, но не представляют как это хранится в базе. Разок пришлось
почти два дня убеждать, что считать так, как они предлагают - нельзя, что
промежуточные результаты не сохраняются, что понятие порядок записей
не применимо если нет уникальных ключей и т.п. И даже после того как
все было объяснено несколько раз - все одно грамотной постановки так и
не удалось получить - все менялось на ходу, но по крайней мере без жутких
претензий по необходимости переделок. Были бы у меня эти кубики -
повесился бы.
В общем, в нашем случае этот подход себя более чем оправдывает.
---------------
Мой, в моем случае - тоже.