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
