[ 
http://issues.apache.org/jira/browse/DERBY-141?page=comments#action_59059 ]
     
Thomas Fischer commented on DERBY-141:
--------------------------------------

Sorry, tomcat gave me an error each time I submitted the subtask, so I 
resubmitted without checking if the submit succeeded. 

> Derby metadata doesn't agree with JDBC specification in some ways.
> ------------------------------------------------------------------
>
>          Key: DERBY-141
>          URL: http://issues.apache.org/jira/browse/DERBY-141
>      Project: Derby
>         Type: Bug
>   Components: JDBC
>     Reporter: A B

>
> NOTE: This bug is different from the bug described in DERBY-137.  DERBY-137 
> states that the Derby metadata always returns JDBC 2.0 result sets even when 
> JDBC 3.0 result sets are required.  This bug states that the JDBC 2.0 
> metadata returned by Derby doesn't comply with the JDBC 2.0 standard in 
> certain (mostly pretty minor) ways.
> There are a series of slight errors in the JDBC 2.0 metadata that Derby 
> returns from the DatabaseMetadata.java API.  The following discrepancies were 
> found in the org/apache/derby/impl/jdbc/metadata.properties file:
> 1) Four of the getBestRowIdentifer queries make an internal call to 
> "getPrecision()" to retrieve the value for the DECIMAL_DIGITS column, but 
> that's wrong.  DECIMAL_DIGITS corresponds to scale, not to precision, and 
> thus these queries should be calling "getScale", not "getPrecision".
> 2) The org/apache/derby/catalog/GetProcedureColumns class, which is a VTI 
> used for implementing the getProcedureColumns() metadata method, returns the 
> wrong value for the LENGTH when the column in question is a character type.  
> LENGTH is specified as "length in _bytes_ of data", but this class 
> incorrectly returns the length in _characters_ for character strings (because 
> the class just calls "getMaximumWidth()", which returns the length in 
> characters; that number should be multiplied by 2 since Java uses 2 bytes per 
> char).
> 3) getPrimaryKeys returns an INTEGER for the KEY_SEQ column when it is 
> specified in the JDBC API as a SHORT.
> 4) getTypeInfo returns some columns as INTEGER when they are specified as 
> SHORT in the JDBC API.  The columns in question here are: NULLABLE, 
> SEARCHABLE, MINIMUM_SCALE, and MAXIMUM_SCALE.
> 5) getIndexInfo returns an INTEGER for the ORDINAL_POSITION column when it is 
> specified in the JDBC API as a SHORT.
> 6) getVersionColumns returns some columns as INTEGER when they are specified 
> as SHORT in the JDBC API.  The columns in question here are: SCOPE, 
> DATA_TYPE, DECIMAL_DIGITS, and PSEUDO_COLUMN.  Note: this query doesn't 
> return any result sets for Derby, so this is a pretty trivial issue, but 
> strictly speaking, it is still incorrect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Reply via email to