Good idea, Knut, thanks for the tip.

David

Knut Anders Hatlen wrote:
"David Van Couvering (JIRA)" <[email protected]> writes:


[ http://issues.apache.org/jira/browse/DERBY-842?page=comments#action_12374799 ]
David Van Couvering commented on DERBY-842:
-------------------------------------------

Knut comments:
<quote>
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).
</quote>
and Kathey mentions on email that we should strive for the SQL States to be the 
same on embedded and network client drivers, to which I wholeheartedly agree.

The problem is, fixing this is turning out to be a bit tricky, because the 
message for XCL16 is

XCL16.S=ResultSet not open. Operation ''{0}'' not permitted. Verify that 
autocommit is OFF.


The reason this is a problem is becuase ResultSet.checkForClosedResultSet()  is 
a generic method called by many (about 30) methods of ResultSet, and the 
particular operation being attempted is not specified.

So, I could fix this by
(a) changing the message for XCL16 to not specify the operation
(b) use the string "<unspecified>" in the client code (I'd internationalize the 
string so it can be translated)

Any opinions?  Otherwise I'll go with option (b)


Isn't this case similar to those where you have added .0 and .1 as a
suffix? For instance,

  XCL16.S.0="ResultSet not open."
  XCL16.S.1="ResultSet not open. Operation {0} not permitted."

On the other hand, Rick's suggestion (Throwable.getStackTrace) sounded
very fancy! :)

Reply via email to