[ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12424615 ] Rick Hillegas commented on DERBY-694: -------------------------------------
You may be able to generate a transaction severity error by invoking a user-written procedure which in turn raises some transaction severity Derby exception. I don't know how to fake an ABNUOWRM in a client-side LOB. It may not be possible today if none of the methods are actually forwarded to the server. Perhaps this is a red herring. > Statement exceptions cause all the connection's result sets to be closed with > the client driver > ----------------------------------------------------------------------------------------------- > > Key: DERBY-694 > URL: http://issues.apache.org/jira/browse/DERBY-694 > Project: Derby > Issue Type: Bug > Components: Network Client > Affects Versions: 10.1.1.1 > Reporter: Oyvind Bakksjo > Assigned To: V.Narayanan > Priority: Minor > Attachments: DERBY-694.html, DERBY-694_upload_v1.diff, > DERBY-694_upload_v1.stat, DERBY-694_v2.diff, DERBY-694_v2.stat, > DERBY-694_v3.diff, DERBY-694_v3.stat, StatementRollbackTest.java > > > Scenario: > Autocommit off. Have two prepared statements, calling executeQuery() on both, > giving me two result sets. Can fetch data from both with next(). If one > statement gets an exception (say, caused by a division by zero), not only > this statement's result set is closed, but also the other open resultset. > This happens with the client driver, whereas in embedded mode, the other > result set is unaffected by the exception in the first result set (as it > should be). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
