The forum for ZeosLib 7.2 Report problems. Ask for help, post proposals for the new version and Zeoslib 7.2 features here. This is a forum that will be edited once the 7.2.x version goes into RC/stable!!
My personal intention for 7.2 is to speed up the internals as optimal a possible for all IDE's. Hope you can help?! Have fun with testing 7.2
SELECT b.RDB$RELATION_NAME, b.RDB$FIELD_NAME, c.RDB$FIELD_LENGTH, c.RDB$CHARACTER_LENGTH FROM RDB$RELATION_FIELDS b
INNER JOIN RDB$FIELDS c ON c.RDB$FIELD_NAME = b.RDB$FIELD_SOURCE
WHERE b.RDB$SYSTEM_FLAG = 0
ORDER BY b.RDB$RELATION_NAME, b.RDB$FIELD_POSITION
For one Varchar(20) field you get:
c.RDB$FIELD_LENGTH = 80
c.RDB$CHARACTER_LENGTH =20
And the:
TZQSQL.Field.Datasize=81
TZQSQL.Field.Size=80
I think TZQSQL.Field.Size sould be 20. I want to change this for my Zeos. Now my Question is, when I change TField.Size to real character length will this cause other problems or side effects?
and In which units of zeos-comments have to change it? There is too many units I searched for ".size" found something else.
you are joining a long standing discussion here with that topic. First: For Zeos with Delphi things already should be correct because the DataSize of the TStringField is writable there.
With FPC things are different. FPC core developers have the opinion that AnsiString is meant to be 1 character per byte. No discussion. UTF8 and MBCS are hacks for them. This is why the DataSize property of TStringField is readonly and hardcoded as one byte per character. They would however accept an implementation of a TUTF8StringField, if one was to supply one. Needless to say, that I didn't getz around to doing that.
I had a discussion with Egonhugeist that usually we would have to map everything Unicode and MBCS to using WideString Field to get some decent UnicodeSupport with correct size attributes.
As a side note: I seem to remember that FPC core developers have the same opinion about Widestrings. Widestrings have to be two bytes ber character. Surrogate pairs are not their problem. So the support of TWideStringField effectively only covers the Basic Multilingual Plane. As far as I remember the same goes for Delphi.
Egonhugeist has prepared replacements for Delphi and Freepascal Fields. I am not sure if they already support UTF8 correctly but we could be more free with them. They are not yet activated per default currently.