At 03:10 AM 18/03/2003 +0200, you wrote:

>Hi,
>
>Delphi7 has 37 different TField datatypes (i.e. TFieldType)
>(actually, if you count ftUnknown, it is 38).
>
>I have done quite a bit of searching but have been unable to
>find a comprehensive list of which TFieldType maps to which
>FB/IB field type.
>
>I have copied Delphi's field types here, I would appreciate
>if someone could map them to FB, please.

Mappings are approximate, at best. Generally, Delphi gets it right all by
itself.

>While it is true that some of this could be handled through
>domains, some are harder to do so (such as ftGuid, ftWideString
>etc.)

You shouldn't (in general) be aiming to "map" data types that are not
supported. If you must, you can recast them, using the appropriate
"AsXxxxxx" method.

>Is it really a good thing that FB has such few field types

FB has nearly all of the data types you need for normal usage. A GUID type
would be very useful and has been discussed. "Field type" is a client-side
concept. Delphi provides a wider range of field types than would map to
all data types in any RDBMS, including some that are not data types at all.

>(no flames please, this is an authentic passenger opinion :-),
>does anyone know if things are likely to change with FB2;
>shouldn't a 'relational database for the new millenium' be
>richer in this aspect too :-)

So, what do you think is missing? How could the database be made "richer"
with respect to data types?

>ftString - char or varchar
>ftSmallint - smallint
>ftInteger - smallint, integer or Int64 (numeric(18,0)
>ftWord - unsigned short, not supported, use a constrained integer
>ftBoolean - not supported yet
>ftFloat - float, but avoid it; double precision
>ftCurrency - decimal or numeric, with suitable precision
>ftBCD - decimal or numeric, with precision > 0 and < 5
>ftDate - date in dialect 3, not supported in dialect 1
>ftTime - time in dialect 3, not supported in dialect 1
>ftDateTime - timestamp in dialect 3, date in dialect 1
>ftBytes - not directly supported, can use OCTETS charset with CHAR()
>ftVarBytes - not directly supported, can use OCTETS charset with VARCHAR()
>ftAutoInc - not supported
>ftBlob - Blob sub_type 0
>ftMemo - Blob sub_type 1
>ftGraphic - store as Blob sub_type 0 and handle graphic attribs in client
>ftFmtMemo - not directly supported
>ftParadoxOle - not applicable
>ftDBaseOle - not applicable
>ftTypedBinary - not applicable
>ftCursor - not applicable
>ftFixedChar - not applicable, use ftString
>ftWideString - can be used with char/varchar in characterset fss_unicode
>ftLargeint - should support int64 but not properly implemented in Delphi
>6; don't know whether it is fixed in Delphi 7
>ftADT - not applicable
>ftArray - should support array types, but not properly implemented in Delphi
>ftReference - not applicable
>ftDataSet - not applicable
>ftOraBlob - not applicable
>ftOraClob - not applicable
>ftVariant - not applicable
>ftInterface - not applicable
>ftIDispatch - not applicable
>ftGuid - not directly supported, can manipulate
>ftTimeStamp - not applicable (use TDateTime)
>ftFMTBcd - not applicable

A lot of Delphi field types "got in there" to solve driver
incompatibilities and are vendor-specific.

The best guideline you can get for yourself is to set up a test app with a
TDataset-compatible query object, prepare the query, instantiate the field
objects for the returned fields using the Fields editor, and then inspect
the field objects created by Delphi, to see what types Delphi
interpreted. Except for a few bugs in Delphi's implementation, it is
mostly right.

By the way, for future reference, this is not a Delphi support list....

heLen