Hi,

I have a Firebird database living on a FreeBSD server. I did not specify a charset when the database was created.

I have a table with a string field defined as VarChar(10).

When I use SqlDB and retrieve the Size of that field via...

FDataset.FieldDefs[AIndex].Size

SqlDB returns 10, which is correct.

But when that exact same code above is run via Zeos, it returns 40.

Anybody know why?

I'm using Zeos from the SubVersion repository:

http://svn.code.sf.net/p/zeoslib/code-0/trunk
Revision: 2209

The same result is returned using Zeos and a MySQL 5.5 database, where the field was also created as VarChar(10).

Regards,
- Graeme -

TFieldDef.Size is expressed in bytes. Zeos, IIRC, assumes a conversion from any charset to utf8 could be made. Since UTF8 is up to 4 bytes per char, a VarChar(10) can need up to 40 bytes to be represented in the dataset. Don't forget that the translation to utf8 can happen in fe. the client library (libmysql, fbclient,...).

Ludo

Ludo Brands wrote

TFieldDef.Size is expressed in bytes. Zeos, IIRC, assumes a conversion from any charset to utf8 could be made. Since UTF8 is up to 4 bytes per char, a VarChar(10) can need up to 40 bytes to be represented in the

I assumed it has something to do with Unicode, but because I never specified a text encoding for the database when I created it - this confused me.

I would have imagined that there might be two "size" properties.

1) .Size - which is the same value as specified in the DDL scripts

2) .DataSize - which might be larger than .Size in the case of Unicode encoded database.

The problem I have with Zeos, is that I can't limit my text input in GUI applications now... Normally the .Size property would have been used, but now Zeos reports 4x the size, so all varchar(10) fields now look like they can store 40 characters, instead of only 10.

Does Zeos have some other property I can use that will match the size given via the DDL scripts? Alternatively I thought of "faking" the real character size in the tiOPF backend, but I can't be sure what encoding the database is in, so I don't know by what value to divide .Size with.

Regards,
- Graeme -

Graeme Geldenhuys wrote / napísal(a):

Yes like in case of TField, where is (for ftString): Size: max.length in characters used in f.e. DB-aware controls DataSize: max.length in bytes used f.e. for allocating buffer size in record

It is known pain, that causes either:
A.) you have enought long buffer, but then DB-aware MaxLength is incorrect or
B.) you have correct MaxLength, but data are truncated

It leads me to thinking, that there is need for extend TFieldDef with DataSize just like in TField
(and make DataSize independent from Size ... now are they related: DataSize:=Size+1 ... so for SBCS it can be as now and for Unicede encodings it can be fe: DataSize:=Size*4+1;)

-Laco.