[
http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12426256 ]
V.Narayanan commented on DERBY-694:
-----------------------------------
Doing a getSqlCode() on NetSqlCa in the above case was returning a -1. This
value is less than ExceptionSeverity.STATEMENT_SEVERITY(20000) hence it was
passing in my previous patch.
I did not however have a way of ever deciding on this as the right method to
check for exception severity. (I would have needed to generate a ABNUOWRM with
severity > STATEMENT_SEVERITY)
My only lifeline in this case was through the following
<cutting and pasting from the comments above>
c.1) I inferred that the getSqlCode() contains the
severity information from the code for
SqlExceptionFactory40 where in the getSQLException
method we check for errCode >=
ExceptionSeverity.SESSION_SEVERITY.
c.2) This method is called from
SqlException.getSQLException() which in turn passes
to this as parameter return value of getErrorCode().
c.3) getErrorCode() inturn obtains the error code from
sqlca_.getSqlCode() when sqlca_ is not null.
To test the above inference I needed a way of generating an ABNUOWRM with
severity greater than STATEMENT_SEVERITY becase in this case getSqlCode()
cannot be -1. But I wasn't able to generate this case. I have already mentioned
this in the above comments.
NetSqlCa.getSqlState() on the other hand does not return me a default value
like -1 but returns 22012 from which the severity is derived. So I can be sure
that getSqlState does return me a valid value from which I can call the
ExceptionUtil methods to derive severity .
I did'nt feel safe sticking to the getSqlCode way which is based on an
inference and a test that passes because a default value of getSqlCode is
lesser than severity value. Hence I decided to stick to the getSqlState method.
If there is someone who can guide me into generating a test case that can
generate a ABNUOWRM with severity > STATEMENT_SEVERITY I most humbly request
for guidance from them.
thanx
Narayanan
> 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, DERBY-694_v4.diff, DERBY-694_v4.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
