db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject SQLState for result set already closed (was Re: [jira] Commented: (DERBY-842) Internationalize messages in PreparedStatement to Section in org.apache.derby.client.am)
Date Sun, 16 Apr 2006 16:40:25 GMT
Knut Anders Hatlen (JIRA) wrote:

>jdbc4/TestResultSetMethods.java fails too since on the client
>ResultSet.checkForClosedResultSet() uses SQL state XJ012
>(ALREADY_CLOSED) whereas EmbedResultSet.checkIfClosed() uses XCL16
>(LANG_RESULT_SET_NOT_OPEN).
>
>  
>
It seems to me that the client message here should match embedded and
the SQLState selection should go like this:
1) Match the standard
2) Match embedded if there is no exception for the error defined in the
standard but it exists in embedded.
3) Make a new SQLState if neither 1 nor 2 apply.

Whatever we can do to create a seamless transition  between client and
embedded is good.  Ideally I think  we just want users to be able to
change their URL or DataSource and that's it.

Question:  Looking at the SQLState documentation at
http://db.apache.org/derby/docs/dev/ref/rrefexcept71493.html, I see
Table 23. Class Code XCL: Non-SQLSTATE.  What does "Non-SQLSTATE" mean
exactly?  Is it just a catch all for SQLStates that don't fall into one
of the other categories?

Kathey





Mime
View raw message