So IMHO there must be:
1. allocated space in record buffer in size 4*TFieldDef.Size+1
2. redefine meaning of Size property (as number of bytes not
characters) and create fielddefs with Size*4
Yes, those are the possible solutions. Good thing about the second
option, is that a user can do that on his own if he wants to use UTF-8,
just create persistent fields with a field size of 4*the amount of
characters. I'm not sure if we have to change this. It's a problem the
programmer has to deal with, I think...
I see here these possible problems/disadvantages:
1. In many cases (dynamic build or ad-hoc queries) is creating
persistent fields not very effective (or complicated)
2. allocation of space in record buffer is based on TFieldDef objects
(see TCustomBufDataset.GetFieldSize) and TFieldDef object are created by
TSQLConnectors in AddFieldDefs method, so setting Size in persistent
field does not solve whole problem, because each SQLConnector must set
Size also
3. in TStringField is Size used also to determine default DisplayWidth
(for TDBGrid) and in Delphi also for setting MaxLength in TDBEdit
(so here we can see, that Size is used like max.number of characters
rather than bytes)
4. incompatibility of Delphi (if we reclasiffy Size as number of bytes
not characters)
So I would prefer 1st way (increase buffer size, may be if we will
support only BMP then 3*Size+1 will be sufficient)
So Size remains as "character length"
hm, according to
http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size is Size
number of characters
but according to
http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size is Size number
of bytes in underlaying database
Yes, that's indeed the problem. But there's also the .DataSize property,
so we could use that.
Yes, but DataSize is defined only in TField not in TFieldDef class
If we will add DataSize property also for TFieldDef class and overload
TFieldDef.Create method with additional parameter DataSize, then
SQLConnector would specify both information: "character size" (for
displaying purposes) and "byte size" (for buffer purposes)
Maybe... if the pressure on the bugtracker gets too high, I'll bow and
change this. (I think 25% of all existing db bugs are related to this
and people who do not understand anything about encodings.)
but TField is created from TFieldDef and
TField.Size=TFieldDef.Size ... so isn't it curious ?
Not that when you want to use UTF-16 (or 32) you have to use
TWideStringFields.
So TWideStringField is "no-encoding-agnostic" field (is it designed to
be everytime UTF-16 encoded) ?
No. It's designed to contain an array of two-bytes records. In fact you
can use it to store UCS-2 data, but not UTF-16. Same story as with
ansi/UTF-8.
Yes I understand now.
Laco.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
