Dimitry SibiryakovМногие со мной не согласятся

Безусловно!!!

Dimitry Sibiryakovно я бы не рекомендовал его для новичков

А я бы вот как раз наоборот рекомендовал бы!

Dimitry SibiryakovСлишком уж он вычурный

Толковый словарь русского языка УшаковаВычурный: Замысловатый, излишне затейливый, искусственно осложненный

Можно раскрыть хотя бы один из синонимов???

Dimitry Sibiryakovпосле него изучение других серверов даётся с трудом

Так может проблема не в нем, а в "других серверах"?

Dimitry SibiryakovДа и "нестабильность" API (они быстро из recommended становится
deprecated) тоже настораживает.

Можно уточнить временные рамки "быстро" в Вашей трактовке? Замечу, что Deprecated никоим образом <> Discontinued! Например, приложения, использующие DB-Library (вспомните сколько ей лет) прекрасно работаю с 2005. Про ODBC вообще промолчу.

Dimitry SibiryakovУгу, именно таков он и есть. Я бы только добавил "не соответствующий
общепринятым канонам (то бишь ANSI стандарту)".

Хоть бы капельку аргументации. Ну, или, хотя бы, IMHO. Особенно на счет совместимости с ANSI и в сравнении с другими СУБД. :)

Dimitry Sibiryakov"Прекрасно работают" значит поддерживают все фичи/типы данных, включая
новые?

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

Dimitry SibiryakovКстати, что нынче является "наиболее прямым" (т.е. быстродействующим и
"нативным") методом доступа? Универсальные прослойки типа ODBC такими не
являются по определению.

OLE DB которая напрямую работает с TDS протоколом. Ну, да, конечно, голимый API на С++ - это небыстродействующий метод доступа. :)

Dimitry SibiryakovПоскольку сам я с ним не сталкивался (пока),

Это пять!!! Зато какие безапеляционые суждения о вычернутости, "нестабильности" API и совместимости с ANSI.

Dimitry Sibiryakovсуждение вынесено из вопросов несчастных, которые пытаются перейти с MS SQL на, например, Firebird. Каждый второй пытается задействовать временные таблицы там,
где достаточно простых запросов, что уже выглядит подозрительно.

Безусловно, но только под подозрение должна подпадать, в первую очередь, квалификация этих "несчастых", а не сервер, с которого они переходят.

Dimitry SibiryakovНу и перлы типа SELECT INTO вместо стандартного INSERT SELECT...

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

Dimitry SibiryakovТо, что я пока не трогал его грязными лапами, ещё не значит, что я не
открывал BOL и соседний форум

Здорово! Жду аргументацию Ваших, пока безапелляционных, заявлений по результатам прочтения BOL и соседнего форума. Ссылки приветствуются. Особенно на посты "несчастных", чей моцх был выеден MS SQL и они решили перейти на Firebird.

2 Dimitry Sibiryakov

Посмотрел:

1. hvlad так же, как Вы не понимает разницы между SELECT ... INTO и INSERT ... SELECT. То, что это является расширением стандарта SQL не делает MS SQL (так же как и Oracle, имеющий аналогичное расширение) несовместимым с ANSI, а предоставляет больше возможностей. Вопрос про временную таблицу - это из моей любимой поговорки: "Задавайте вопрос по самой задаче, а не по выбранному Вами способу ее решения". Это даже вынесено в Рекомендации по оформлению сообщений на bid=1.

2. Вообще не понял к чему Вы привели этот линк. Select из хп сделать нельзя (без танцов с бубнами) ни в MS SQL, ни в Oracle, но что там, что там хп может возвращать курсор. В MS SQL, как и в Firebird хп м.б. "селективной", т.е. выдавать результат SELECTом находящимся в ней. В чем здесь вычурность или не соответствие стандарту?

3. Жесть! Вместо того, чтобы честно признаться что Firebird не поддерживает предложение FROM в инструкции UPDATE Вы скатились в философские заключения на тему проектирования бд. В каком плане в инструкции UPDATE, без учета расширений, MS SQL не соответствует стандарту?

1 = 4.

И так, что же показали Ваши ссылки:

1. Подтверждения вычурности я в них не нашел, ибо все приведенные Вами "подтверждения" на поверку оказались "слабыми сторонами" реализации диалекта SQL в Firebird, по сравнения с расширениями (обращаю внимание, это именно расширения и стандартный синтаксис поддерживается) в T-SQL
2. Ни один из приведенных примеров не показал, что MS SQL не соответствует стандарту ANSI и в какой его части.
3. Кмк, вопросы задавались слабоквалифицированными специалистами.
4. Вы пытаетесь выдать за вычурность и не соответсnвие MS SQL стандартном Ваше незнание как базового синтаксиса T-SQL, так и его расширений.