Мимо пробегал... .... Мне это не нравиться.
Это никому не нравится :) Безусловно, по-своему логично, но претензии ораклоидов к реализации сводятся почти исключительно именно к этой детали; хочется, чтобы length('') == 0.

Мимо пробегал...Вы не находите что всё-таки есть разница между "результат неопределён" и "результат зависит от настроек"?
Я нахожу, что я сказал совершенно однозначную фразу: "невозможно предсказать результат выполнения скрипта [по тексту этого скрипта]". Мало того, SergSuper, уверенно предсказав результат, продемонстрировал именно ту опасность, которую я имел в виду.

Впрочем, изначально я не имел намерения говорить о недостатках MSSQL - исключительно ответ собеседнику, который "не читал, но осуждает".

Мимо пробегал...Что касается стандарта ANSI, точнее его внимательного прочтения. Я лично его не читал, не знаю читал ли его Leonid, сомневаюсь что Вы его читали,
Читал. И знаю, как он построен. Почему и отношусь к заявлениям "нарушает стандарт" очень, назовем так, скептически - ANSI SQL построен так, что его трудно нарушить. Если говорить о стандарте-2003 - в него ухитрились внести как SEQUENCE, так и IDENTITY, но не сделали при этом напрашивающегося, актуального и абсолютно естественного шага - IDENTITY, запитанного от SEQUENCE. Полагаю, понимаете, почему.

Мимо пробегал...но думаю в MS то кто-то его читал, не просто так же они назвали ANSI_NULLS
Думаю, читали. Мало того, если Вы обратите внимания - я нигде не говорил, что MSSQL нарушает стандарт. Но делать из этого (и только из этого) вывод, что любая другая реализация стандарт нарушает - значит, демонстрировать неграмотность и неумность.

eNoseкроме строковых, есть и другие типы. для каждого делать своё поведение на null?
Практической необходимости в этом я не вижу. Увижу - скажу, что хорошо бы сделать. Именно с блобами в Oracle связан не слишком удобный момент, проистекающий из реализации блобов - необходимость использовать функцию EMPTY_BLOB(). Это вызывает те же самые проблемы - скажем, проверка на пустоту блоба вообще говоря должна идти через coalesce (dbms_lob.length(blob), 0)=0 - но поскольку работа с блобами - не самая эффективная задача, таких проверок обычно избегают, не оставляя полям значения EMPTY_BLOB.

SergSuperА вот кстати что ANSI стандарт говорит.
Браво. Кстати, Вы прочитали то место, где говорится, что <literal> - это вовсе не строковая константа?

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

Теперь второй комментарий - о соответствии стандарту вообще. Позволю себе другую фразу из стандарта (SQL'92, сейчас нет под рукой новее)


Сколько из этих операций Вы найдете в MSSQL? Говорите, он соответствует стандарту?

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

LeonidВыберите/напишите контролы, где не надо ставить галочки .
Решение, безусловно, лучшее чем ничего, но недостаточное. Оно позволяет ставить меньше пяти тысяч галочек - безусловно. От ошибок, однако, оно не спасает.

Впрочем, если Вы скажете, что "нестандартное значение" нужно одной из ста или одной из тысячи галочек - я соглашусь, что вероятность ошибки сообразно падает. Правда, сообразно падает и ценность этой фичи, и критичность ее отсутствия.

Наследование то же ни кто не отменял.

LeonidА чем вас пугает вызов "хранимки" sp_executesql?
Вызов хранимки меня не пугает. Меня пугает идея "формировать sql из данных" - я не вижу пути понять это иначе, чем


Эта идея меня "пугает" - правда, это уже тема другой беседы.

Если хотите, считайте, что я придираюсь к словам.

LeonidВот, блин, и приплыли. Одно тянет за собой другое.
Есть такой эффект. В данном случае в Oracle именно что сказали А, но не решились сказать Б.

Из этого не следует, что не стоило говорить А. Даже без Б - с моей точки зрения - его стоило сказать. Но лучше было бы сказать и Б тоже; с этим я согласен.

Gluk (Kazan)А меня ПУГАЕТ, то что ADO имеет наглость лезть ВНУТРЬ запроса.
Не совсем так. По моим ощущениям, ADO - продукт примерно того же класса, что и BDE, со всеми теми же преимуществами-недостатками, но именно в данном случае большого криминала нет - ADO не лезет в запрос, а оборачивает его, вызывает хранимку, передавая ей текст запроса.

Правда, какую-то бяку с параметрами при этом я видел.

^{В качестве веселого оффтопика: когда я показал оракловый трейс с bind-переменными, мой оппонент заподозрил, что это трейс BDE. По его мнению, при передаче необернутого запроса параметры должны были быть подставлены на клиенте - в смысле, переменные заменены значениями прямо в тексте запроса.}

Gluk (Kazan)Неправильно выправлять кривизну сервера кривизной методов доступа
Безусловно. Собственно, после того разговора мне стало много понятнее, почему с точки зрения MSSQL-евцев все надо делать на хранимках. В частности, иначе там идет принудительный cursor_sharing=force.

LeonidНе отдавайтесь на волю ощущениям :) А то как в анекдоте: Так вы всю науку к @#$% сведете :) ADO - это ActiveX обертка поверх OLE DB. OLE DB же сам по себе очень эфективный механизм.
Мне ближе точка зрения Alexey Sh - про "изведение чудачеств".

Leonid
BDE здесь ни при чем и классы и способы низкоуровневого доступа у них разные. Сравнивать их по меньшей мере не корректно.
Хм. Как бы Вам сказать.. смотреть можно с разных точек зрения.

ADO, как и BDE - это некий "толстый провайдер". То есть не просто интерфейс драйверов к БД, но также куча нетривиальной логики. Как и у BDE, как и у других продуктов подобного класса - у него есть как преимущества (возможность пользоваться этой логикой) так и недостатки - эта логика, а также вызванные ей ограничения реализации, проявляются и мешают в достаточно неожиданных местах.

LeonidНу да, в конце концов, вам с этим возиться, не мне.
Безусловно :) С тем моментом, что как раз "возиться" и оказывается ненужным.

Собственно, пример на эту тему только что был на RSDN - там человек спрашивал, пройдет ли в оракле запрос, составленный для DB2 и MS, и ему посоветовали заменить coalesce(...) на просто field is null. По моим текущим ощущениям, именно это - типичный случай.

SergSuperА как было бы удобно если для int-а при присваивании нуля подставлялся бы NULL.
Это было бы очень удобно, если бы в полях ввода ноль и null отображались бы одинаково, а в логике обработки они практически всегда означали бы одно и то же.

SergSuperЭто ж coalesce(field ,0)=0 можно было бы заменить на просто field is null !
Можно было бы. "Как было бы удобно" определяется тем, насколько часто это нужно, а насколько часто - мешало бы.