[
https://issues.apache.org/jira/browse/DERBY-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169770#comment-13169770
]
Dag H. Wanvik commented on DERBY-5533:
--------------------------------------
Thanks, Rick. I decided to move them to ParameterMappingTest instead; only half
the new tests concern updatable result sets, after all.
Uploading patch derby-5533 with the tests and a fix which changes the class
LossOfPrecisionConversionException to OutsideRangeForDataTypeException,
wrapping 22003 and updates the usage sites, all of which are covered by the
tests I believe. I also removed the old error 22015.S.1, which was only used by
the client.
Note: whereas the old error message indicated the *value* that was out of range
for the conversion, the 22003 erro rmessage shows the target type XXX for
setXXX. However, for getXXX, the type given in the error message by the
embedded driver not the target Java type (e.g. short in getShort), but the
correspondig SQL type, i,e.. SMALLINT. I think this is the way it is because on
the server, the same conversion methods are also used in CAST, where the target
type is an SQL type, not a Java type. I chose to let the client use the same
type strings as embedded does. If we want to improve on this later, we can do
that for both drivers.
Running regressions, please review.
> Client differs from embedded when rs.updateInt overflows: 22015 vs 22003
> ------------------------------------------------------------------------
>
> Key: DERBY-5533
> URL: https://issues.apache.org/jira/browse/DERBY-5533
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Reporter: Dag H. Wanvik
> Priority: Minor
> Attachments: derby-5533-repro.diff, derby-5533-test.diff
>
>
> stm.executeUpdate("create table t(i smallint)");
> stm.executeUpdate("insert into t values 1,2,3,4");
> ResultSet rs = stm.executeQuery("select i from t");
> rs.next();
> try {
> rs.updateInt(1, 100000);
> } catch (SQLException e) {
> // client: 22015 vs embedded 22003
> }
> According to the standard, 22015 should be used for INTERVALs ("interval
> field overflow"). 22003 seems more correct, the standard uses that for
> "numeric value out of range".
--
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
