надеюсь ла здесь по теме. Проблема такая:
у меня ошибка если я пытаюсь протолкнуть следуеще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 после сиквела :))
---------------
Для меня не сильно критично и даже кое-что делать в нем удобнее.
Например, лепить таблицы и структуру - в ЕМ мне не так удобно. А вот
лепить всю аппликцию в нем - это да, это полная труба.
самый простой способ - это сделать грамотную иерархию вьюх-кубиков
---------------
Угу... А потом придет кто-то умный и попросит добавить столбец в таблицу.
У меня такое - регулярно. Консультанты понимают в том, что и как надо
считать, но не представляют как это хранится в базе. Разок пришлось
почти два дня убеждать, что считать так, как они предлагают - нельзя, что
промежуточные результаты не сохраняются, что понятие порядок записей
не применимо если нет уникальных ключей и т.п. И даже после того как
все было объяснено несколько раз - все одно грамотной постановки так и
не удалось получить - все менялось на ходу, но по крайней мере без жутких
претензий по необходимости переделок. Были бы у меня эти кубики -
повесился бы.
В общем, в нашем случае этот подход себя более чем оправдывает.
---------------
Мой, в моем случае - тоже.

Теория говорит, что должно иметь место Отсечение...
вот-вот... у меня к нему всегда предубеждение было, во всех языках :)) "а вдруг реализация такая, что не отсечет?" :))))
Например, лепить таблицы и структуру - в ЕМ мне не так удобно.
никогда не лепил в EM "по-крупному" :) Время от времени тока смотрел, как он тот или иной объект заскриптовывает. А так - все ручками...
А потом придет кто-то умный и попросит добавить столбец в таблицу.
тоже бывает часто... но не так, чтоб напрямую. "Умные" - они обычно чаще фичу просят. А как ее на уровне БД разруливать - это уже наше (мое?) дело. А столбы добавлять... Ну, вот надо, к примеру, 1 добавить... и вспоминаю я, что месяц назад мы уже добавляли какой-то столб в той же подсистеме... полнотекстовый поиск по скриптам с репортинговыми вьюхами и хранимками, ищем "старый" столб и рядом с ним вписываем новый :))))))) Ну, утрирую немножко, но бывает и так.
Есть вот еще другой сорт "умных". Это программисты, использующие наш софт. Они, конечно же, все сами лучше всех знают "Anforderungsliste vom 01.02.2005, Punkt XYZ. Der Report "ABC" braucht ca. 50 Sekunden. Kann man hier vielleicht ein Paar Indizes auf die Tabelle setzen, damit er schneller wird?" Угу, покажи мне еще эту таблицу, хранимку и тормозной участок в коде, посмеемся вместе
--------------
Авиатор х#ев

"а вдруг реализация такая, что не отсечет?"
----------------
В продуктах дяди Билли я об этом говорю такЖ
"А вдруг в следующий раз не отсечет!!!"
А так - все ручками...
----------------
Мне быстрее сделать черновик в Аксессе и выдернуть из него скрипт для
MS SQL - есть такая тулузка.
А как ее на уровне БД разруливать - это уже наше (мое?) дело.
---------------
Если сроки не давят - можно и поразруливать, а если давят, то приходится
заранее озаботится тем, чтобы разруливание было максимально простым
и быстрым.
...и вспоминаю я...
...полнотекстовый поиск по скриптам...
---------------
Вот-вот. А как что-то пропустишь? Отсюда и растут ноги у требования об том,
чтобы _все_, что касается одной таблицы (или группы) было в одном файле.
Тагда надо найти и серьезно поправить только ОДИН файл. К тому же он лежит в той же папочке, где и форма с миддле-сервером. С вьюхами
такое, увы, не проходит.
покажи мне еще эту таблицу
--------------
Ихь хабе шпрейхен зи Дойчь нихт. Но в общем случае отдается интерфейсная
часть с полным запретом использовать недокументированные возможности.
Так что Kann man hier vielleicht ein Paar Indizes просто не возникает.

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

но по таблицам все сгруппировать невозможно
------------------
Теперь оцени - в процедурах нет Join'ов. Вместо них вызывается другая
процедура.
бизнес-логика все интенсивнее выносится на сервер
------------------
Есть такая тенденция. Считается, что можно менять архитектуру базы и
апп-сервера, не меняя клиента. Пока особых преимуществ не вижу - все
что нужно можно написать на любом из языков, но чем более плоской
выглядит база для апп-сервера, а апп-сервер для клиента - тем лучше.
Но ее напрямую...
----------------
В этом месте я начинаю жалеть, что нет триггеров на select'ы

Теперь оцени - в процедурах нет Join'ов.
а в бизнес-логичных их и нету почти... там все больше ножницами (insert/update) таблицы кромсать приходится :)
Есть такая тенденция. Считается, что можно менять архитектуру базы и
апп-сервера, не меняя клиента. Пока особых преимуществ не вижу - все
а у нас нету миддл-тиера :) вернее, исторически было некое его огрызочное подобие + огромная часть бизнес-логики на клиенте. Вообще (опять же, в наших условиях) особого смысла в 3-х-звенке не вижу.
Мало того, не без моего влияния стали активно вырезать бизнес-логику из клиента и переливать непосредственно на сиквел-сервер в хранимки и триггеры. Преимущества дали о себе знать буквально через месяц. Кодирование, деплоймент и суппорт заметно упростились.
--------------
Авиатор х#ев

...особого смысла в 3-х-звенке не вижу.
Кодирование, деплоймент и суппорт...
------------------
Я тоже не видел, пока не начал делать. Эффект, примерно такой же, как
и при переносе кода в процедуры. Единственный недостаток - кода все же
получается чуть больше, но сам код - проще и понятней.

А почему бы не так?

create procedure get_count
	@text_value varchar(50)
as
if @text_value is null 
	select count(id) from mf_type where text_value is null
else
	select count(id) from mf_type where text_value = @text_value

veni, vidi... expuli

А что? Мне нравится.