Здравствуйте,

Хочу разобраться как равотает JDBC c хранимыми процедурами в Sybase.
Я планирую писать хранимые процедуры с довольно сложной логикой внутри,
которые на выход должны выдавать ResultSet. Поэтому, я хотел бы разобраться
как это правильно делать. Поискав в сети, я нашел, что для этого не требуется
декларировать выходные параметры. Я просто создаю примерно вот такую процедуру:

create procedure myproc as
select * from Address
select * from Person

потом, я запускаю её через JDBC драйвер.
Создаю CallableStatement и из него достаю

resultSet1 = callableStatement.getResultSet()

соотватственно получаю результат выполнения "select * from Address".
далее судя по документации если я делаю

callableStatement.getMoreResults();
resultSet2 = callableStatement.getResultSet();
то должен получит результат выполнения "select * from Person".

Если меня на выходе интересует только результат "select * from Person",
то будет ли resultSet1 грузиться на клиент? Если да, то как это обойти?
Можно ли как то сразу добраться до результата напрямую, минуя
getMoreResults() вызов?

Может кто-то может подсказать какие-то другие подходы долучения
ResultSet-а из процедуры?

Еще буду благодарен за ссылки на описание работы JDBC c Sybase + stored procedures.
(Кроме Sybase документации)

Спасибо

iLLerНа клиента можно и не тянуть все наборы, все зависит от него и какие комманды он посылает. Но по большому счету, multi result set - это плохая идея. Нужно разбивать на атомарные процедуры, которые вызывать выборочно и последовательно, в зависимости от условий.
Да, я согласен. Всё тянуть мне очень не нравится самому. Но разбивать на процедуры, это тоже еще та петрушка получится. Я просто думал, что может драйвер не будет тянуть все result sets на клиет, пока их перебираешь.

Но вообще, я немного разочарован. Я предполагал, что в Sybase должно поддерживаться что-то
типа: return #temporary_table. Т.е. декларация одного возвращаемого результата. На сколько, я видел
в Оракле и даже MSSQL такая фишка есть.

Может всетаки есть какие-то обходные пути, кроме разбиения на подпроцедуры?

Dmitry.все селекты без INTO уходят на клиента.
Про INTO я как-то и не подумал сам.
Может это и есть выход? Просто пихать ненужные селекты
во временные таблицы. А таблицы удалять по мере ненадобности.
А в конце процедуры сделать последний селект который и будет
единственным результатом. Что думаете?

Господа,

В моем случае действительно интересует вернуть именно один результат. При этом, не
должно быть лишних пересылок между клиентом и сервером.

Отказываться от промежуточных запросов, в общем случае, не хотелось бы, потому как,
иногда, надо сделать пару запросов, как то скомпоновать/обсчитать данные, а потом уже
возвращать финальный результат.

Исходя из этой дискусси и моих тестов, я делаю вывод, что имеет смысл использовать
временные таблицы для хранения промежуточных результатов. Например, если сделать вот так:

то в процедуре у нас 2 запроса, а результат возвращается
только один.

Я использовал вот этот код для получения этого результата.

При этом не требуется вызывать getMoreResults() метод.
Конечно я мог бы использовать курсор вместо временной таблицы,
но в этом случае я получил бы 2 ResultSet объекта. И как
результат выполнения Java кода получил бы первый select.
Хотя с курсором тоже можно исползовать INTO и тогда опять будет
все в порядке.

Т.е. самым полезным оказался ответ от Dmitry. Секрет заключается
в правильном использовании INTO.

Конструктивная критика все еще приветствуется, господа ...