Rick Hillegas wrote: > Hi Dan, > > Thanks for your comments. Some responses follow. Cheers-Rick > > Daniel John Debrunner wrote:
>> In the JDBC api section, I assume it means that this "In all other >> cases, DatabaseMetaData and ResultSetMetaData will report BOOLEAN >> columns as JDBC type java.sql.Types.SMALLINT." means the JDBC typid >> column will be Types.SMALLINT, but the SQL type name will continue to be >> BOOLEAN. E.g. ResultSetMetaData.getColumnNameType() will return >> "BOOLEAN". > > I don't understand what it means if type names don't agree with type > codes. I was planning to report these columns as type code > java.sql.Types.SMALLINT and type name "SMALLINT". I think that's wrong, the SQL name/type of the column is BOOLEAN, not SMALLINT. As for "type names don't agree with type codes", I'm not sure what you mean by agree, these are two different type domains, JDBC for the Types.XXX values and SQL for the SQL names. The JDBC driver is providing a mapping between domains, there is not any requirement for agreement in names to ids. >> Why Types.SMALLINT, and not Types.OTHER or Types.BIT? >> >> > I chose SMALLINT for a tactical reason: It is the type currently used > if the Derby client selects from one of our BOOLEAN-typed system > columns. Does the embedded driver report these columns as SMALLINT? Types.BIT was the recommended value for BOOLEAN SQL types in JDBC 2, look at the Java type to JDBC type mapping for Types.BIT. > I'm hoping that this mapping will have fewer compatibility > issues for existing applications. So I assume you mean existing applications from other databases that currently support BOOLEAN SQL type. Do you know what JDBC type id those databases return? Dan.
