db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Re: [jira] Created: (DERBY-447) getBoolean() throws data conversion exception for DECIMAL type in J2ME/CDC/Foundation
Date Fri, 08 Jul 2005 22:53:44 GMT


(Lance, see question to you below)

>>>>> "DJD" == Daniel John Debrunner <djd@debrunners.com> wrote:
DJD> Dag H. Wanvik wrote:
DJD> > DJD> There's some inconsistency here, the ResultSet getter methods are
DJD> > DJD> converting from SQL data types to Java data types. This supportsConvert
DJD> > DJD> method takes two arguments, both of which describe SQL data types.
DJD> > 
DJD> > Yes, you are right. Something for Lance to clarify :) 
DJD> > But it would seem the no-args supportsConvert() should return false
DJD> > until we add support for CONVERT.
DJD> And just to be clear, this is the JDBC CONVERT function from section C.5
DJD> of JDBC 3.0, correct?


DJD> I think there is some issue with CONVERT in JDBC 4.0, where the format
DJD> of the second argument is changing, from INTEGER to SQL_INTEGER or
DJD> something like that?

Hmm.. I did a short check..  The DataBaseMetaData.supportsConvert has
int (from java.sql.Types aka JDBC types/SQLtypes) for both arguments
(both in JDBC 3.0 and early draft 4.0), which makes sense since the
API speaks of describing the support/behavior of CONVERT, and this
conversion all happens in the SQL domain.

[On a side note: actually the Javadoc for supportsConvert speaks of
(unqualified) CONVERT, without being explicit on this being the C.5
escape JDBC CONVERT, not the SQL character set CONVERT, but I guess
that's kind of obvious..?]

Also, in both the JDBC 3.0 and 4.0 spec, the escape function CONVERT
has SQLtype as the second argument, "value" being given as the first.

The PreparedStatement "setter"/ ResultSet "getter" functions mappings,
though, convert from and to Java types, given by the tables in the B

I think the problem is that section in the JDBC 4.0 spec
( in 3.0) erroneously states that
DataBaseMetaData.supportsConvert says ANYTHING about the mapping for
getter methods. Interestingly, the corresponding section on conversion
for *setter* methods makes no mention of
DataBaseMetaData.supportsConvert (section in 4.0 as well as
in 3.0). Nor do the IN, OUT, INOUT descriptions.

> Data Type Conversions
> The recommended ResultSet getter method for each JDBC type is shown
> in TABLE B-6 on page B-210. This table also shows all of the
> possible conversions that a JDBC driver may support. The method
> DataBaseMetaData.supportsConvert(int fromType, int toType) returns
> true if the driver supports the given conversion.

Lance, do you agree this is wrong? If it is correct, please explain
what I am missing here..!

Notwhithstanding this, the Derby implementation of no-args
DataBaseMetaData.supportsConvert() returns true, indicating we support
C.5 CONVERT, which we do not AFAICS, and I suggest we make a JIRA for


View raw message