Hello

There is a great difference between a standard and the goal of it, a standard states clearly what conditions must be meet to
comply with it. Unfortunately JDBC standard are poorly specified in the metadata area and that means that there is a long distance
between the standard and the goal.

I agree that the mapping of the same database type to several JDBC types makes no sense, and there is an error to include int64
in type info.

There are new mapping for blob and array (previously not included). The mapping uses blob mappings that are included previously
in the ResultSetMetaData.getDataTypeName() with a minor change. The new mappings are

blob sub_type <0 maps to Blob
blob sub_type 0 maps to LongVarbinary
blob sub_type 1 maps to LongVarchar
blob sub_type >1 maps to other
array maps to other

Now DatabaseMetaData.getTypeInfo(), DatabaseMetaData.getColumns() TYPE_NAME and ResultSetMetaData.getColumnTypeName() must
return coherent values.

Also I add some create_params values.

About the bug in NON_UNIQUE column I hope I solved it today. We can't change the actual column type because possible existing
implementations, but now there is a change in getBoolean() and the value returned now must be the good one.

The problem with ASC or DESC is that the database meta data tables apparently does not contain this information, so we can't
report it.

Regards
Blas Rodriguez Somoza

----- Original Message -----
From: "Stephan Perktold" <stephan.asa@...>
To: "Roman Rokytskyy" <rrokytskyy@...>
Cc: "Blas Rodriguez Somoza" <blas@...>
Sent: Tuesday, July 30, 2002 6:08 PM
Subject: Re: Bugs in the Firebird Java/JDBC Client


> Dear Roman Rokytskyy and Blas Rodriguez Somoza,
>
>
> I would like to comment your answer to my last mail which mainly contained
> the following points:
>
> - Type names should be directly usable in "CREATE TABLE" statements.
> - InterBase/Firebird specific subtypes should be possibly hidden by the
> driver.
> - All database specific types should be fully reported (including
> "BLOB SUB_TYPE 1" for LONGVARCHAR).
> - Identical data types should not be mapped to different (compatible)
> JDBC types.
> - The CREATE_PARAMS should be documented with the commonly used
> names "length" and "precision,scale".
>
> Maybe this is not explicitely stated in the JDBC specification, but the goal
> of a JDBC driver is to provide an abstraction layer between the database and
> the application. This is visible from the well designed JDBC interface to
> retrieve lots of meta data information. Of course all this doesn't help if
> the retrieved information is incomplete and needs knowledge about database
> specifics at the application level.
>
>
> > ... In fact several drivers use the same
> > mapping for different database types.
> >
>
> That's true, the same JDBC types can be mapped to different database types,
> because all database specific types should be fully reported (they differ in
> attributes like precision, signability, ...). On the other hand identical
> database types should not be mapped to different (compatible) JDBC types.
> Otherwise data types reported by meta data retrievals don't match those
> used by the creation, leading to an endless loop in our dynamic database
> structure update system.
>
> I send you an extract from our code containing the type mapping I currently
> use with
> InterClient as a workaround to it's incomplete type mapping. Additionally I
> attach a file containing type mapping reports of some databases I tested.
>
>
> > > 3) DatabaseMetaData.getIndexInfo:
> > > NON_UNIQUE wrong type and wrong value (always 'F').
> >
> > Solved, now returns F/T depending of the value in FB.
> >
>
> Note: getBoolean(column) returns false for 'T' and 'F'.
> As suggested by my original bug report you should use type SMALLINT with
> values 0 and 1 to represent boolean values beeing this the most efficient
> and most compatible representation.
>
>
> > > ASC_OR_DESC always null (should be 'A' or 'D'). Even if in the case of
> > > Firebird the sort sequence is an index attribute, it should be reported
> > > by all columns of the index. Only so it is possible to distinguish
> > > between ascending and descending variants of indices with the same
> > > columns.
> >
> > The standard states that the Ascending or Descending value can be null.
>
> That maybe right for the standard, but makes it unusable for us.
>
>
> BTW: Today I noticed that the FBField-instances aren't cached in the
> FBResultSet, they are unnecessarily created on every call to any getter
> method.
>
>
> I hope my suggestions can be a valuable contribution to this project. Since
> I'm not confident with the native Firebird API, I can't contribute more
> actively.
>
>
> Best regards,
> Stephan Perktold
> (stephan.asa@...)
>
>