Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 14 Dec 2011 22:45:31 +0000 (UTC)
From: "Dag H. Wanvik (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <685610834.13105.1323902731731.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <335618798.2171.1323716731479.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5533) Client differs from embedded when
 rs.updateInt overflows: 22015 vs 22003
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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