db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: ResultSet.getConcurrency() behaves differently on client and embedded
Date Mon, 27 Feb 2006 13:51:36 GMT
Knut Anders Hatlen wrote:
> "Lance J. Andersen" <Lance.Andersen@Sun.COM> writes:
>> We clarified this in JDBC 4 spec
>> Once a ResultSet has been closed, any attempt to access any of its
>> methods with
>> the exception of the isClosed method will result in a SQLException being
>> thrown. ResultSetMetaData instances that were created by a ResultSet that
>> has been closed are still accessible.
> Thanks, Lance! I'll go through all the ResultSet methods and file a
> Does the same apply for Statement? I didn't see a similar comment
> about Statement objects in the spec.

Hi Knut Anders,

I don't exactly have an answer for you, but observed the following in 
the 'EmbedStatement.java' file:
"/* The close() method is the only method
   * that is allowed to be called on a closed
   * Statement, as per Jon Ellis.

I found in the JDBC4 spec that Jon Ellis is a former JDBC spec lead. It 
is also stated in a comment that every public method in the class must 
call 'checkStatus', which throws an SQLException if the statment is closed.

For the close method itself, the JDBC4 JavaDoc says this:
"Calling the method close on a Statement object that is already closed 
has no effect."

Derby seem to behave according to the spec on this point, but maybe 
someone else has something more to add?


View raw message