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] [Commented] (DERBY-5773) SQLException.getErrorCode() returns -1 on client
Date Mon, 21 May 2012 11:20:41 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280087#comment-13280087
] 

Knut Anders Hatlen commented on DERBY-5773:
-------------------------------------------

To reproduce, run the following code fragment:

        s.execute("create table t(x int)");
        s.execute("insert into t values 1,2,3,null,3,2,1");
        try {
            s.execute("alter table t add constraint c unique(x)");
        } catch (SQLException sqle) {
            System.out.println(sqle);
            System.out.println("Error code: " + sqle.getErrorCode());
        }

With the embedded driver, it will print:

java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would
have caused a duplicate key value in a unique or primary key constraint or unique index identified
by 'SQL120521131744740' defined on 'T'.
Error code: 30000

And with the client driver:

java.sql.SQLIntegrityConstraintViolationException: The statement was aborted because it would
have caused a duplicate key value in a unique or primary key constraint or unique index identified
by 'SQL120521131946000' defined on 'T'.
Error code: -1
                
> SQLException.getErrorCode() returns -1 on client
> ------------------------------------------------
>
>                 Key: DERBY-5773
>                 URL: https://issues.apache.org/jira/browse/DERBY-5773
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client, Network Server
>    Affects Versions: 10.8.2.2
>            Reporter: Knut Anders Hatlen
>
> On the embedded driver, SQLException.getErrorCode() returns a value representing the
severity of the error. On the client driver, it returns -1 for almost all exceptions. (It
has some logic to make session-severity errors return 40000, but the other errors return -1.
And SQLWarnings will preserve their error code, which is 10000.)
> The error code gets lost when DRDAConnThread calls getSqlCode(getExceptionSeverity(e)),
as getSqlCode() always returns -1 for exceptions:
> 	private int getSqlCode(int severity)
> 	{
> 		if (severity == CodePoint.SVRCOD_WARNING)		// warning
> 			return 100;		//CLI likes it
> 		else if (severity == CodePoint.SVRCOD_INFO)             
> 			return 0;
> 		else
> 			return -1;
> 	}
> It's not just its returning -1 for exceptions that's problematic in the above method.
Returning 100 for warnings causes them to be ignored by the client, since that error code
is interpreted as end-of-data. After the changes for DERBY-129 DRDAConnThread.getSqlCode()
won't be called for warnings, though, so it should be safe to remove the SVRCOD_WARNING case
from the method. (The real end-of-data warnings use a different code path, from DRDAConnThread.doneData().)

--
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

        

Mime
View raw message