pkarklin funikovyuri Чего ей богу - какое сравнение возможностей вы хотите если у вас на любой недостаток MSSQL будет ответ - "by design"? Оно понятно что "by design" но, согласитесь, неудобством от этого быть не перестает. ;)
Пока я не видел приведенных Вами, действительно недостатков, хотя они, безусловное есть. ;) Честно говоря, от Вас я ожидал более серьезного подхода и вскрытия более глубинных проблем, чем вложенность INSERT ... EXEC... Вы же по непонятным мне причинам скатываетесь до уровня "нахрапистого юнца", которому абсолютно по-барабану, что написано в документации, и видители, он придумал, что его конструкциия должна работать так, как ему хочется, а результате все оказалось совсем не так, и он от этого сильно страдает.
Уважаемый, если не затруднит покажите, где я написал что хочу чтобы моя конструкция должна работать так, как мне хочется? Я писал о том, что TSQL не замкнут относительно своих операций. И что это ставит перед разработчиком необходимость писать 2 вида хранимых процедур - первый для вызова с "клиента" и второй для вызова с кода tsql. Конструкция INSERT ... EXEC... приведенная, кстати, вами как способ получения результатов работы ХП обладавает рядом недостатков и на универсальное решение претендовать не может.
Что же до ваших ожиданий - imho, pkarklin, вы многовато на себя берете.
pkarklin
funikovyuri1. невозможно написать код который одинаково будет работать вне зависимости от того вызван он с клиента или из другого tsql кода.
Возможно. И Вы это прекрасно знаете. Но Вы опять зациклились на возврате резалтсета из хп. В прощлый раз обсуждение этой темы как раз вылилось из моего заявления о неудобстве возврата набора данных из хп в Oracle через рефкурсор.
Нет, не знаю. Более того - вы тоже не знаете и MS не знает - это факт. Напомню мы говорим о том что на TSQL код ХП который возвращает результат своей работы с помощью select "на клиента", т.е. не через output параметр типа курсор сложно использовать из другого кода на TSQL. Т.е.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create proc t1
as
select 1
select 2 -- к этому курсору получить доступ из TSQL вообще невозможно, т.к.
go -- exec into позволяет получать только первый резалтсет
create proc t2
as
exec t1 into #some_table
go
create proc t3
as
exec t2 into #some_table2 -- не возвожно, т.к. exec into cannot be nested
go
pkarklin
funikovyuri2. невозможно написать код который будет работать как в set xact_abort on так и в set xact_abort off
Возможно, ибо управление этой опцией в Ваших руках. В хп, имеющей set xact_abort on, Вы можете вызвать хп, имеющую set xact_abort off.
funikovyuri3. если код пишется для режима set xact_abort off и использует проверку кода ошибки после каждого выражения то такой код не будет работать как только его вызовут из кода в котором set xact_abort включен в on
Прежде, чем что-то заявлять, стоит подумать или, хотя бы попробовать. Перечитайте мой предыдущий абзац.
Угу, например, есть код написанный для off (процедура t1) и имеющий логику обработки тех или иных ошибок. Этот код вызывает ХП, которую написали для режима on (процедура t2). Так вот логика обработки ошибок в вызвавшем коде вызываться никогда не будет, т.к. как в случае ошибок в t2 MS SQL прервет батч и откатит транзакцию. В принципе, возможно, для когото это не проблема, но мне она нервы трепала не раз. Ну и сравнивать это все с нормальным механизмом обработки ошибок основанном на исключениях я бы не стал. (собственно если учесть что в MSSQL2005 они есть, MS тут придерживается того же мнения)
pkarklin
funikovyuri4. в tsql нет коллекций и локальных переменных
Нет ни коллекций, ни глобальных переменных. За использование последних я бы вообще расстреливал. Первые, как уже указывалось, можно реализовать.
Казалось вам можно просто согласиться...
Реализовывать можно что угодно, но преимуществом я бы это не назвал. TSQL это не тот язык в котором удобно создавать свои коллекции ассоциативные массивы и другие подобные вещи. Про глобальные переменные - обычно их ругают за замусоривание глобальной области видимости - в Oracle это не так, т.к. переменные там ограничены областью видимости пакета. Так что это преимущество и imho неплохое
pkarklin
funikovyuri5. динамический sql выполняется только с правами вызывающего пользователя (это нельзя изменить)
Это справедливо для версий до 2000.
Слава Богу.
ЗЫ насчет же отсутствия "глубинных недостатков" MS SQL - давайте закончим с TSQL потом поговорим о чем-нибудь еще.
