db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-2601) Server SQLException error codes are not returned to client
Date Fri, 25 May 2012 10:20:23 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-2601:

    Attachment: d2601-1a.diff

Attaching d2601-1a.diff which makes the server send error codes to the
client. Derbyall, suites.All and the compatibility test passed with
the patch.

In the current code, when an exception happens on the server, the
server always sends an SQLCARD with SQLCODE=-1, and this value is used
as error code when the client generates the SQLException.

Simply changing the server to send the actual error code in the
SQLCODE field wouldn't work, though, since the client uses the sign of
the SQLCODE to tell whether the condition is a warning or an error.
Positive values are interpreted as warnings, and negative as errors.

The client doesn't depend on the negative value being -1, so we could
send any negative value to tell that an error occurred. The patch
exploits this by encoding the always non-negative error code seen on
the server as a negative value in the SQL code:

  sqlCode = -errorCode - 1

When the client generates an SQLException, it can convert the SQL code
back to the original error code:

  errorCode = -sqlCode - 1

More detailed description of the changes:

* drda/org/apache/derby/impl/drda/DRDAConnThread.java

  - Push down some of the logic that determines the SQLCODE from
    writeSQLCAGRP() to getSqlCode().

  - Make getSqlCode() return the error code encoded in a negative
    integer if the exception represents an error.

  - Remove unused severity parameter in writeSQLCARD().

* client/org/apache/derby/client/am/Sqlca.java

  - Added getErrorCode() method to convert SQL code to error code.

    if the connection is in auto-commit mode. This is needed in order
    to match the error codes returned by the embedded driver in
    auto-commit (see TransactionResourceImpl.handleException() for the
    corresponding code in the engine). (This does not happen
    automatically otherwise because the server-side connection is
    never auto-commit, even if the client-side connection is.)

  - getUnformattedMessage() now shows the error code instead of the
    SQL code.

* client/org/apache/derby/client/am/SqlException.java

  - If the exception is generated from an SQLCA, use getErrorCode()
    instead of getSqlCode() to initialize the error code.

* client/org/apache/derby/client/am/SQLExceptionFactory40.java

  - Check for error code only if the sub-class of SQLException cannot
    be determined from the SQL state. (I don't know why the original
    code checked the error code in the first place. The embedded
    driver only looks at the SQL state.) Now that the error code is
    something else than -1, the early checks for error code for
    example made syntax errors that happened in auto-commit mode
    (whose error codes match TRANSACTION_SEVERITY) would be returned
    as SQLTransactionRollbackExceptions instead of

* testing/org/apache/derbyTesting/functionTests/master/testclientij.out

  - Update master to expect the correct error codes.

*  testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java

  - Added helper method that checks the error code.

* testing/org/apache/derbyTesting/functionTests/tests/derbynet/BadConnectionTest.java

  - Expect the correct error code.

* testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/J2EEDataSourceTest.java

  - Use new helper method to check error codes.

* testing/org/apache/derbyTesting/functionTests/tests/lang/ErrorCodeTest.java

  - Enable for client/server.

* testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java
* testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ShutdownMaster.java
* testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ShutdownSlave.java

  - Expect correct error codes.
> Server SQLException error codes are not returned to client
> ----------------------------------------------------------
>                 Key: DERBY-2601
>                 URL: https://issues.apache.org/jira/browse/DERBY-2601
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>            Reporter: Kathey Marsden
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_triage10_9
>         Attachments: d2601-1a.diff
> ErrorCodes from returned SQLExceptions are not retained in client.  e.g. in the example
below, client reports an errorcode of -1 instead of 30000.    If DRDA allows it would be good
for the errorCode to be retained
> [C:/test] java -Dij.showErrorCode=true org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby:wombat';
> ij> create table t(i nt, s smallint);
> ERROR 42X01: Syntax error: Encountered "" at line 1, column 18. (errorCode = 30000)
> ij> exit;
> [C:/test] ns start -noSecurityManager &
> [2]     5712
> [C:/test] Apache Derby Network Server - alpha - (1) started and ready to accept
connections on port 1527 at 200
> 7-04-20 17:36:27.188 GMT
> [C:/test] java -Dij.showErrorCode=true org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby://localhost:1527/wombat';
> ij> create table t(i nt, s smallint);
> ERROR 42X01: Syntax error: Encountered "" at line 1, column 18. (errorCode = -1)
> ij>
> Once this has been fixed ErrorCodeTest can be enabled for client.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message