funikovyuriС точки зрения остального кода на tsql резалтсет уходит в никуда.

По поводу способа возврата резалтсета из хп у нас уже был здесь спор. Поищите. По сабжу.

Рассмотрим пример:


и


Почему в первом случаи вы знаете, "куда" уходит резалтсет, а во втором нет?! Раз Вы не указали "вкуда" направлять результат, он будет отправлен на клиента. В отличии от Oracle поведение результата выборки в MS SQL однозначно, будь она AdHoc запросом или запросом в хп.

funikovyuri -- как мне использовать результат работы AnotherTestProcThatUsesTestProc


funikovyuriPS про "уходит на клиента" это круто

Это действительно "круто", ибо куда еще можно уходить результату SELECT?!

funikovyuriну не мне же вас в faq по mssql отсылать

Действительно, не надо. Я его и так хорошо знаю...

funikovyuriчтож вы умолчали про эти "фичи"?

Эт не "фичи". Эт "by design". Почему Вас не удивляет то, что в char(1) нельзя вписать более 1го символа? Да и workaround этого "by design" есть.


funikovyuriбудете удивлены, но есть такое свойство как замкнутость, в данном случае имеется в виду что обычно в языке программирования результатом любой операции языка является объект этого языка. В случае TSQL это не так

И каким объектом языка в Oracle будет результат INSERT?

funikovyuriИзвестно каким - записью в соответствующей таблице.

С таким же успехом результатом SELECTа будет резалтсет. Не правда ли?

funikovyuriВы можете получить эту запись с помощью SELECT. А вы как думали?

Вы можете получить это резалтсет на клиенте. А Вы как думали? В том то и дело, что не стоит натягивать на SQL понятие "замкнутости" и придумывать для INSERT в качестве результата запись в таблице, которая не является ОБЪЕКТОМ ЯЗЫКА!

funikovyuriтогда можно поговорить про обработку ошибок в MSSQL 2k ... а именно отсутствие исключений...

А что об этом говорить. Их там действительно не было. Разве с этим кто спорит?!

funikovyuri"костыли" в виде SET XACT_ABORT ON? Согласитесь, что писать универсальный код с SET XACT_ABORT ON сложно,

Гм... Универсальный в моем понимании - это код, в котором ошибка любого рода приводит к полному откату транзакции, что и достигается с помощью SET XACT_ABORT ON. А уж для распределенных транзакций без него вообще никуда.

funikovyuriа с постоянным анализом кода возврата каждого SQL-выражения долго и неудобно.

Анализ наличия ошибки после каждой инструкции необходим только в случие различной реакции на ошибку для каждой инструкции.

funikovyuri(с Yukon я не работал),

Ну, и не работая, наверно слышали, про try...catch?

funikovyuriНу т.е., я надеюсь, вы согласны что insert/exec это очень ограниченная конструкция

Мать... Мать... Мать... :) Ну не используйте "ограниченную инструкцию" то? Возвращайте набор через курсор в выходном параметре.

funikovyuriи писать универсальный, повторно используемый код на TSQL ситуация с "резалтсетами ушедшими на клиента" только мешает?

Если Вы не будете отправлять их на клиента, то и мешать ничего не будет. У каждой хп должно быть назначение. Возвращает данные на клиента - должен быть SELECT. Данные будут обрабатываться на стороне сервера - курсор через параметр или это вообще должна быть НЕ ХП. Вариант с "не ХП" может быть использован и в задаче "возврата" данных на клиента.

funikovyuriТ.е. вы считаете что Yukon надо сравнивать с Oracle 9, а не 10?

DDL в Oracle не транзакционны.

Ага... Так же, как и SERIALIZABLE не SERIALIZABLE.

Yo.! конечно проблемы :)

Господа, ну ей богу.

Сказано - нельзя INSERT ... EXEC ... быть вложенным, нет я все равно буду пытаться это использовать.

Сказано об ограничениях DDL при снапшоте, нет я все равно буду это использовать.

И после этого кричать: "ну ребятя, ну фигня же это". Еще раз спрощу, почему не кричите "фигня", что в char(1) два символа не влазит?

funikovyuri pkarklin funikovyuriТ.е. вы считаете что Yukon надо сравнивать с Oracle 9, а не 10?

DDL в Oracle не транзакционны.

Ага... Так же, как и SERIALIZABLE не SERIALIZABLE.

Не позорьтесь, и не начинайте того чего не сможете закончить

Я бы посоветовал Вам быть чуть-чуть по-корректней, дабы мне не приходилось Вас посылать в тынц.