pkarklinнесколько датасетов, возвращаемых из ХП я бы это записал скорее в минус в силу их неявности.

Был случай плавающая ошибка: процедура А стала вместо датасета с колонкойА стала иногда выдавать датасет с колонкойБ.
Несколько дней отлавливания ошибки на боевой базе (при этом запустить процедуруА второй раз с теми же параметрами нельзя, она модифицирует данные) при этом процедураА критична для бизнеса.
процедураА в процессе вызывает еще кучу всяких процедур внутри себя и выдает наружу результат выполнения.
В результате оказалось что в процедуре Ж (которая вообще говоря "сбоку припеку" процедуре А и вообще где то на 5 уровне вложенности выполняется только при совпадении определенных параметров менее чем в 5% случаев) разработчиком был забыт "отладочный select". Тестирование процедуры Ж не показало никаких проблем. Поскольку основной функционал процедуры Ж вообще не ожидал от нее датасета и соответственно там было все ок.
После того как обновление процедуры Ж появилась на сервере появилась плавающая ошибка.
поскольку процедура Ж выполнялась раньше чем итоговый селект в процедуре А, то клиент ожидавший 1 датасет ловил датасет от Ж и наступал трындец.

Когда баг был найден (огребая попутно за неработающий функционал) мне хотелось придушить и майкрософтовцев придумавших "сквозные select" и того разработчика.

pkarklinIn_Waitмне хотелось придушить ... разработчика.

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


По п1 не говоря о том что процедуре скоро 5 лет и время на переработку ее и интерфейса никто не выделит, суть в том что функционал предусматривает групповую обработку, с возвратом результата аля васе пупкину нельзя потому что бла бла бла, сереже иванову нельзя потому что тра та та . И как раз этот результат и возвращается в виде рекордсета. Представьте себе что с такой формой работают несколько пользователей, и вам нужно организовать вывод этих результатов, для каждого именно по тем записям которые он пытается изменить. Конечно можно нагородить таблицу логов в которой хранить guid и ид и сообщение и вызывая первую процедуру которая модифицирует, ловить от нее гуид передавать в вторую и потом только получать датасет, но довольно сильно усложняет и так непростой функционал как на сервере так и на клиенте. И обосновать такую доработку и получить на нее акцепт практически нереально.

pkarklinавторНесколько дней отлавливания ошибки на боевой базе ... Когда баг был найден (огребая попутно за неработающий функционал)

Непонятно, почему на это потратили несколько дней?! Если функционал не работал - значит кто-то таки выполнял эту хп и получал левый датасет. Отловить отработку инструкций в хп профайлером - плевое дело.

по п2
это стек вызовов (это уже понятно после того как ошибка найдена) который приводит к появлению ошибки
процедура1 та что все это обрабатывает 300 строк
процедура2 которую она вызывает 1500 строк (куча условных переходов)
процедура3 1000 строк ( курсор и встроенные функции/ хп внутри тоже ветвления всякие)
процедура4 1500 строчек ( опят же куча кода аля если а вызываем хп aaa если б вызываем хп мммм)
процедура5 (с кривым селектом) 200 строчек

При этом почти в каждой процедуре множество условных переходов, в некоторых курсоры и циклы, встроенные функции и прочая бяка разворачивающаяся в многостраничный листинг....
Пользователей которые эту бяку вызывают несколько все работают через апп сервер через единый логин.
Процедуры 2,3,4,5 и еще целая куча других которые я тут не перечисляю, работают еще в куче других функционалов и могут вызываться в любой момент любым другим пользователем через тот же через апп сервер.

Представьте что я не знаю где и почему ошибка, знаю только что приложение говорит все ок. (а "в ложном" датасете как раз все как будто ок, нет ни столбцов какие ожидаются, ни строчек, и поэтому форма никаких сообщений об отбитых строчках не выводит) а на самом деле не проставил галки и не создал операции по паре другой клиентов, клиенты в результате остались мягко говоря недовольны, а точнее без денег.
Что в такой ситуации вы мне предлагаете ловить профайлером? Ей богу если бы я знал как это все настроить для отлова это было просто замечательно....

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

Dimitry SibiryakovIn_Waitаля васе пупкину нельзя потому что бла бла бла, сереже иванову нельзя потому что тра та та
.. И как раз этот результат и возвращается в виде рекордсета. Представьте себе что с такой
формой работают несколько пользователей, и вам нужно организовать вывод этих результатов,
для каждого именно по тем записям которые он пытается изменить.

Столько выкручиваний только потому, что MS SQL не умеет выкидывать из процедур приличные
исключения...


А как ты предлагаешь выдавать исключения в групповой обработке?
Как предпочитают ораклисты все в курсоре делать что ли?

Dimitry SibiryakovТочнее даже так:
И всё это в тех самых триггерах, которых у MS SQL нету.


Ну фу
и что пользователь получит 50 мессажбоксов с ошибками что ли?
Какие нафиг триггеры господа. я вас умоляю. такой функционал на триггер не навесишь.

Bogdanov AndreykDnZPBogdanov Andrey, ну могу только согласиться с этим утверждением. Совершенно верно, как на мой взгляд. Только где противоречие с тем, что мною сказано?Ну вы сказали, что "стоит ставить в упрек СУБД" подобное поведение. А в данном случае вина именно СУБД в том, что она не позволяет в декларации процедуры описать формат возвращаемых данных. То есть требует от вызывающих таки заглядывания внутрь. Работать с этим можно, но вот удобным я назвать никак не могу.

Ну с одной стороны это удобно тем что не надо описание столбцов добавлять.
поменял в процедуре запрос и все.
Но благодаря этой неопределенности имеем фактическое табу на insert into exec... и необходимость передачи данных в временных табличках из процедуры в процедуру если это универсальный функционал использующийся в множестве разных мест.
Даже появившиеся в 2008 табличные параметры имеют ряд ограничений которые сводят на нет их достоинства. Надеюсь в следующих версиях их таки доработают.