Dear David Jencks,

I have got your changes to FBDatabaseMetaData.getTypeInfo:

//BIGINT=-5
//Unfortunately it doesn't seem to be possible to specify INT64 as a
column
datatype
//I'm using NUMERIC(18,0) until something better is available.
//Note that 18 digits is too few whereas 19 is too many.
rows.add(new byte[][] {getBytes("NUMERIC(18,0)"), createShort
(Types.BIGINT)
, XSQLVAR.encodeInt(64), null, null, null,
NULLABLE, CASEINSENSITIVE, SEARCHABLE, SIGNED, FIXEDSCALE,
NOTAUTOINC, null, shortZero, shortZero,
XSQLVAR.encodeInt(GDS.SQL_INT64), null, BINARY});

This changes break our dynamic update strategy of the database
structure. The problem consists in the fact that there is an
inconsistency between creation types (based on this info) and the
effective types as reported by getColumns. This results in repeated
updates.

As discussed with Roman Rokytskyy and Blas Rodriguez Somoza (see
mails from august, 5 with subject '[Firebird-Java] Re: Bugs in the
Firebird Java/JDBC Client') getTypeInfo should always return only
the real data types supported by the database. An eventual type
mapping has to be done by the application layer. Only this allows
the implementation of database independent applications which
implement their own type mapping between desired and supported data
types. In the case of Types.BIGINT the application could also map it
to Types.DOUBLE (52 bit). In all cases getColumns has to return the
same value as used in the create/alter table statements.

Please remove the Types.BIGINT mapping until there is a real INT64
type name available.


Best regards

Stephan Perktold
(stephan.asa@...)