Requirements of getMoreResults()/getMoreResults(int)

Mark Rotteveel mark at
Thu Nov 26 19:11:06 UTC 2015

But does this all mean that getMoreResults() should behave like 

I'd like an answer to that.

As to the previous discussion, is that accessible somewhere?

The rest of this mail can be seen as an argument that further 
clarification or changes might be needed.

My initial guess is it should be seen as CLOSE_ALL_RESULTS, but as a 
non-native speaker I think that (JDBC 4.2, "getMoreResults 
closes any previous ResultSet object returned by the method 
getResultSet." can be interpreted both as "closes all previous ResultSet 
object**s**" and "closes **the** previous ResultSet object, if any". The 
language of the getMoreResults() javadoc ("any current ResultSet 
object(s)") is slightly clearer because it uses plural ("object(s)"), 
but the use of "current" might be taken to point to CLOSE_CURRENT_RESULT.

The fact that getMoreResults(int) requires drivers that don't support 
multiple open results to throw SQLFeatureNotSupportedException when 
CLOSE_ALL_RESULTS is used is confusing. If you don't support multiple 
open results, then Statement.CLOSE_ALL_RESULTS is equivalent to 
CLOSE_CURRENT_RESULT, so why not allow it to be accepted?


On 23-11-2015 23:50, Lance Andersen wrote:
> This is covered in 13.3.3 of the JDBC 3.0 spec and, 13.3.3 of
> the current JDBC spec.
> The JDBC 4 made an attempt to clarify but I would have to go back and
> try and find the discussions and see if any additional clarification
> might be needed (this is the first request in 11 years :-) )
> The original javadoc for getMoreResults was:
> ---
>      /**
>       * getMoreResults moves to a Statement's next result.  It returns true if
>       * this result is a ResultSet.  getMoreResults also implicitly
>       * closes any current ResultSet obtained with getResultSet.
>       *
>       * There are no more results when (!getMoreResults() &&
>       * (getUpdateCount() == -1)
>       *
>       * @return true if the next result is a ResultSet; false if it is
>       * an update count or there are no more results
>       * @see #execute
>       */
>      boolean getMoreResults() throws SQLException;
> ---
> Best
> Lance
> On Nov 22, 2015, at 5:26 AM, Mark Rotteveel <mark at
> <mailto:mark at>> wrote:
>> I just ran into a question on stackoverflow,
>> about the requirements for
>> getMoreResults() vs getMoreResults(int).
>> The description of getMoreResults() says:
>> "and implicitly closes any current ResultSet object(s) obtained with
>> the method getResultSet."
>> As it uses **any** and object**(s)**, this sounds to me like its
>> behavior should be the equivalent of
>> getMoreResults(Statement.CLOSE_ALL_RESULTS), however
>> getMoreResults(int) says:
>> "SQLFeatureNotSupportedException - if
>> DatabaseMetaData.supportsMultipleOpenResults returns false and either
>> supplied as the argument."
>> This was added in JDBC 4, JDBC 3 had no such requirement.
>> So, what is the required behavior for getMoreResults()? Is it always
>> getMoreResults(Statement.CLOSE_CURRENT_RESULT), or is it
>> getMoreResults(Statement.CLOSE_CURRENT_RESULT) in a driver that does
>> not support multiple results, and
>> getMoreResults(Statement.CLOSE_ALL_RESULTS) in a driver that does
>> support multiple open results?
>> If the second, then I think for a driver that does not support
>> multiple open results this distinction is unnecessary, because then
>> closing the current result is the same as closing all results (as
>> there is only one open result); and then the requirement to throw
>> SQLFeatureNotSupportedException for Statement.CLOSE_ALL_RESULTS is
>> also unnecessary.
>> On a related note, the DatabaseMetData.supportsMultipleOpenResults says:
>> "Retrieves whether it is possible to have multiple ResultSet objects
>> returned from a CallableStatement object simultaneously."
>> I think CallableStatement should be changed to Statement as you can
>> call stored procedures (or other statements) that have multiple
>> results also with Statement or PreparedStatement.
>> Mark Rotteveel
>> --
>> Mark Rotteveel
> <>
> <><>
> <>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at <mailto:Lance.Andersen at>

Mark Rotteveel

More information about the jdbc-spec-discuss mailing list