MySQL / clientdataset field mapping ( MySQL 4.0.x/D7 )

MySQL / clientdataset field mapping ( MySQL 4.0.x/D7 )

Post by Deberlange » Tue, 09 Sep 2003 17:20:58


Hi,

I have an application that uses RTTI published properties from a class to
generate, if persistent storage needed, the necessary SQL to the
mysql server for the create table etc...( using a simple 1 class-> 1 table
pattern ) The mapping scheme is : RTTI typekinds ( tkinteger, tkLString
etc..) -> TField Fieldtypes ( ftInteger, ftlargeint, ) -> MySQL datatypes
INT, BIGINT..).
My feeling told me it was a good design to go via the intermediate field
types, as this is what will be used to retrieve the data via datasets. This
allows me to preset the TFields of a dataSet for some class records to be
retrieved, allowing me greater flexibility.
A logical translation for a 64bit integer field was e.g. tkInt64 ->
ftLargeInt -> BIGINT. However when I have a clientdataset with persistent
fields on a form for this, I get an error saying that for this field a
TFMTBCDField type was expected. So, by default, BIGINT gives TFMTBCDField
apparently.

Who/what is responsible for mapping field types ? MySQL dbexpress driver ?
Is there anyway you can overule the default field mapping ? ( I know that
some parameters you can solve by using the persistent fields -- e.g the
required property for NOT NULL fields -- by apparently not the field type
without resulting in errors ? Or is the mapping done in some of dbexpress
.pas units ?

Similarly, I would consider it a loss of information if the application
knows e.g. that a certain field is TGraphicField or TMemoField, but that you
have to use the general TBlobField because that's the default.

Regards
Dirk
 
 
 

MySQL / clientdataset field mapping ( MySQL 4.0.x/D7 )

Post by Deberlange » Fri, 19 Sep 2003 15:52:51

Hi all,

Apparently, by default, a BIGINT MySQL datatype results in a TFMTBCDField in
a dataset
( and not ftLargeInt )
Who/what is responsible for mapping field types ? MySQL dbexpress driver ?
Is there anyway you can overule the default field mapping ? ( I know that
some parameters you can solve by using the persistent fields -- e.g the
required property for NOT NULL fields -- by apparently not the field type
without resulting in errors ? Or is the mapping done in some of dbexpress
.pas units ?

Similarly, I would consider it a loss of information if the application
knows e.g. that a certain field is TGraphicField or TMemoField, but that you
have to use the general TBlobField because that's the default.

Regards
Dirk