On 12/21/2013 04:04 PM, Arne Vajh?j wrote:
On 12/21/2013 1:59 PM, Arved Sandstrom wrote:
On 12/20/2013 08:08 PM, Arne Vajh?j wrote:
On 12/20/2013 9:07 AM, Andreas Leitgeb wrote:
I have to write code to execute runtime-specified SQL-statements,
and there are two things that I wasn't able to understand from reading
the javadocs:
1.)
When would one call .getMoreResults() on a statement instead of just
another rs.next() on the first one (obtained from
stmnt.getResultSet())?
Are these equivalent, or is there really a concept of multiple
ResultSets,
each of which has its own independent set of rows?
Yes.
Some databases support stored procedures returning multiple
result sets.
[ SNIP ]
This might just be me, but I dislike the entire idea. I am aware of the
possibility, I've never used it. To me a stored proc (SP) should adhere
to the same principles as functions or procedures - you try to simplify
your components (and your application) by not having them do multiple
things (side-effects, overly complex return values etc).
I can follow you.
But I have seen SP's return 20+ result sets.
I guess that the argument is to save round trips.
No doubt. I've never been compelled to use multiple result sets myself.
I haven't not once encountered a project where anyone felt the need to
use multiple result sets. So I actually Googled to find out what the
rationale is.
The other is stored procs returning multiple result sets. I had no
success finding any article that provided motivation for the concept:
the authors of a few articles did mention that they wished not to
explain *why*, but just *how*...which is faint praise in my books. :-)
This particular concept seems to me to be much more "we can do this, so
we will".
http://stackoverflow.com/questions/2336362/execute-multiple-sql-commands-in-one-round-trip