> When I looked at this and implemented the BIGINT support, I didnt see
> anything in the spec or javadocs that indicated that the Type returned

from

> a column should be the same as that used to get the sql to create the
> column. In other words, I think the Type to db-specific sql types can be
> many to one. Do you have some evidence that the spec authors intend
> otherwise? I don't remember too clearly but I thought there were some
> hints that the relation between Type and db-specific sql type could be
> many-many.

1) The documentation for getTypeInfo says:
'Gets a description of all the standard SQL types SUPPORTED (!) by THIS
DATABAES'.
Your implementation adds a not really supported type (Types.BIGINT). This
gives a wrong view of the underlying database. The type info for
Firebird.INT64 should only be added from the time on a corresponding type
name is supported in create table statements.

2) getTypeInfo is the only source to retrieve the native type names needed
to create or alter tables using standard SQL statements.

3) I don't approve incosistency between the attributes used to create tables
and those retrieved afterward.

> I would think a more generally plausible algorithm for you would be to
> compare the db specific sql for the Type from the column and the Type from
> typeinfo and decide if they are compatible.

The code in my last mail was just a pseudo code to clarify the concept. The
real implementation is of course more complex. I follow a strategy to always
have the database structure as near as possible to the desired one. This has
already proved to be a good strategy, because it automatically upgrades to
new features available by newer driver and/or database versions (i.e.
converting from Timestamp to the new available Date type). I don't want to
start a discussion about upgrade strategies, because that's applications
specific and hasn't anything to do with the driver. Only if the JDBC driver
reports real non manipulated meta data informations the application has the
possibility to be database independent.

> does your algorithm work for any other databases?

Yes, we support the following:
INTERBASE / FIREBIRD
MS SQL SERVER
IBM DB2
ORACLE
ADABAS
PERVASIVE SQL SERVER


Best regards
Stephan