[
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
