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.
|ResultSetMetaData.isReadOnly() also returns wrong results||Open||Unassigned|