White OwlВообще-то, такие вещи делать не рекомендуется.


Это почему это ? Кем не рекомендуется ? Ничем это не запрещено и не ограничено, ничего плохого не сулит. ASE (и MSSQL ) тем и хороши, что позволяют в любом месте выполнять любые операторы TSQL в любом количестве. Множество любых DML можно выполнять в любом месте и в любом сочетании.

UrsegoЕсли хранимая процедура возвращает record set, могу ли я добавить SQL statement (DELETE, не SELECT) после SELECT-а, возвращающего record set?


Можешь. Можешь добавить даже не только DELETE, но и INSERT или UPDATE, или даже еще один SELECT, который формирует еще один record set.

White OwlГлавное чтобы клиент умел принимать множественные резалтсеты из хранимой процедуры.


А он всегда должен уметь. Иначе он неправильно написан, не по спецификации (есть некий алгоритм работы, предписываемый для реализации в клиенте). А тогда он вообще не будет работать правильно. Так что множественные наборы данных можно формировать всегда. Возможно, некоторые клиенты (как то Delphi в ранних версиях) не будут видеть
наборы данных кроме первого, но работать при этом они ДОЛЖНЫ,
иначе они просто написаны с ошибкой.

White Owl
SELECT bla-bla-bla… <return result>
DELETE bla-bla-bla…
GO // the end of proc
практически равнозначно
SELECT bla-bla-bla… <return result>
SELECT tra-ta-ta… <return second result>
GO // the end of proc


Ничего не равнозначно. В первом случае один набор данных,
во втором - два.

White Owl
Но в случае delete второй резалтсет пустой.


Нет, в первом случае не будет второго набора.

Пустой набор - это набор колонок но без записей. А тут не будет даже набора колонок.

White Owl
Клиент получив (или отменив) первый резалсет посылает на сервер команду "отдавай следующий" и тогда замороженая хранимая процедура продолжит работу. Любая другая sql команда отменит работу ХП сразу после первого select.

Что означает второе предложение ? Какая -такая SQL-комманда на клиенте ?
Я не понял .
А клиент может , обработав первый набор, сделать только одну из двух вещей :

Попросить следующий набор данных

либо отказаться от следующего набора.

В любом случае все будет работать.

А вот если он зависнет как красная девица в восторженном ожидании непонятно чего -- это ошибка программирования клиента. Такого быть не должно.

iLLer
Так и есть. Причем в PowerBuilder, к примеру, ДВ основанное на ХП не
способно получать несколько резалтсетов, оно может получить заданный по
номеру, все стоящие перед ним будут игнорированы, а ПБ получив нужный
заканчивает выполнение ХП. Не очень приятное поведение ДВ, но ничего не
поделаешь.


Поясню: ДВ - это Data Window, грид, в котором показывается набор данных.

А вот если подумать, то окажется что такое неприятное поведение PowerBuilder или того же Delphi на самом деле - единственно возможное поведение. Что Дельфям делать с ТРЕМЯ таблицами ? Одну он в грид засунет, а где ему несколько гридов брать ? Для того, чтобы несколько наборов обработать, надо иметь какую-то логику программную, а создатели RAD хотят описать все исключительно метаданными, без такой логики. Так что им несколько таблиц просто некуда засунуть ...

Кстати забыл сказать. Лучше еще ставить
set nocount on в начале таких процедур. Почему - долго объяснять...

White OwlНабора колонок не будет, а резалтсет будет. Ну вот такой странный резалтсет :) А как еще назвать-то?


Не будет резалтсета. Или ты имеешь в виду то, что в Open Client называется Result ? Ну так там все - Result. причем от DELETE бутет Result типа ROWCOUNT (number of affected rows). Но его может не быть вообще, если установить set nocount on (DONE_INPROC не посылаются в этом случае).

White Owl
Если например клиент пишется на ODBC, то в приведеном примере команда delete не будет выполнена пока клиент не скомандует SQLMoreResults(hStmt);


Будет. Ты еще не забывай, что в пределах заполнения одного буфера обмена клиент и сервер асинхронны. Если даже будут включены DONE_INPROC, но буфер серверный не заполнится еще, то этот твой DELETE запросто выполнится со свистом. Не выполнится он только, когда от предыдущего SELECT-а еще буфер не освободился.

White Owl
"Вообще-то, такие вещи делать не рекомендуется." :)


Так не "не рекомендуется", а просто нельзя.

iLLerИ что тут невозможного, реализовать тупое открытие-закрытие курсора после получения нужного резалтсета, ведь впередиидущие он же способен пропустить?! И в данном случаем алгоритм работы клиента БД написан разработчиками ПБ и обходной путь единственный - не использовать для выполнения такой ХП датавиндов, а вызывать ручками.

Я не про это говорил. Это возможно реализовать, но НЕ НУЖНО. Потому что в RAD ты тыкаешь пальчиком в процедуру и говоришь "А покажи ка ее данные в таком гриде". Максимум что можно сделать (и как ты говоришь сделано в PB) - "А покажи ка мне третий набор данных из этой процедуры в этом гриде".

А чтобы сказать " а покажи ка мне объединение первого, второго, и , если соблюдаются такие-то условия, пятого, а иначе, шестого набора в этом вот гриде, причем недостающие колонки надо заполнять так-то и так-то" нужно писать программу, а не пальчиком тыкать. Задача же разработчиков RAD - дать возможность тыкать пальчиком. А программу ты всегда сам можешь написать...

iLLer, что там кому чего не позволяет ? Я не понял.

iLLer
Так вот, если в PB создать ДВ основанное на этой ХП, и указать что надо
брать данные 2-го резалтсета, то все прекрасно работает, за исключением того, что update не выполняется. Т.е. данные возвращенные 2-м селектом в ДВ попадают, но хп дальше этого селекта не выполняется.


Быть такого не может. Если это так, то PB надо срочно выкидывать на помойку как редчайший отстой. Повторяюсь - ЕСЛИ ЭТО ТАК.

Может сами чего нахимичили ?
В процедурах стоит set nocount on ?

Кроме того, и вообще такого быть не может, может быть что выполнение приостанавливается, но чтобы совсем дальше не выполнялось -- вообще быть не может. Механизмов таких нету.

White OwlЕсли клиент считает что он все выбрал уже, он может закрыть стейтмент в любой момент. PB выбрал все что считает нужным (SQLFetch(hStmt) вернул SQL_NO_DATA). И значит все, можно закрывать курсор.

Ну так если он этот "курсор" закроет, то сервер автоматом дальше пойдет. Сервер может висеть только на неотосланных данных.

Говорю еще раз - такого быть не может. Если это так, то надо писать в Sybase по какому-то конкретному поводу, жаловаться на жизнь и открывать CASE-ы. Ибо это баг.