Zeoslib Portal

Hi All,

I experienced a difference in behavior with ZeosLib 7.2.0 Beta.

1. Using Firebird
With a Firebird 2.5.2 simple database, the FLOAT fields are interpreted (I think), by ZeosLib, differently in C++Builder (RAD) 2009 and C++Builder XE2. I tested in a Windows 7 64 bits OS. In C++Builder RAD 2009, the FLOAT is interpreted as TFloatField. On the other hand, in XE2 the same field was interpreted as TSingleField.

2. Using SQLite
With a SQLite 3.8.11 equivalent database, the REAL fields are interpreted as TFloatField both in RAD 2009 and XE2.

I also noticed that TSingleFields are present in XE2 but not in RAD 2009.

I'm trying to implement a Multi-DBMS TDataModule and this subject is kind of a problem, as I have TField descendants in design time.

Is there a way to overcome this TFloatField/TSingleField mapping difference in C++Builder XE2?

Thank you in advance.

Best,

Marcelo.

[Synopses]
Windows 7 64 bits
ZeosLib 7.2.0 Beta
Firebird 2.5.2 and SQLite 3.8.11
C++Builder RAD 2009 and XE2 Professional.

Hello Marcelo,

I did not introduce that change but to me that seems like Zeos leveraging the new possibilities of new Delphi/BCB versions. The Firebird float datatype is a float with single precision. So the best option is to represent it as a TSingleField in newer Delphi and BCB versions. Delphi/BCB 2009 doesn't have a TSingleField so the only option for representing this field type was to use a TFloatField.

My suggestion: Don't use persistent fields. Let Zeos handle the creation of field objects and do the modifications to the field objects in the AfterOpen event.

Other possibilities:
1) Extend your database field to be a double precision field. I assume that this field type will always be represented by a TFloatField.
2) Modify Zeos - introduce some kind of parameter that tells the firebird driver to revert to the olf behaviour. If you want to go that route, I probably could give you some pointers on how to do that.

With best regards,

Jan

Hi Jan,

You were right, it is indeed a BCB/Delphi behavior.

Changing the respective Firebird's column to DOUBLE PRECISION resulted in a persistent TFloatField. And this is alright, because SQLite's FLOAT type has 8 bytes, as Firebird's DOUBLE PRECISION.

Also, I'll try to test your hint about using AfterOpen to avoid persistent TField descendants.

About this subject, just an extra comment: do you think ZeosLib would implement that "Data Type Mapping" as AnyDAC (now FireDAC) did?

Reference: http://docwiki.embarcadero.com/RADStudi ... FireDAC%29

If you think so, I would like to put myself as a volunteer to ZeosLib developers' group to try it.

Thank you in advance.

Marcelo.

Hello Marcelo,

currently there is not enough manpower to implement that kind of mapping. But if you want to try to do it yourself, I could try to give you some pointers. But beware because it really seems like a big task as you probably would have to modify all Zeoslib drivers and the components tha work on top of them.

With best regards,

Jan