[fpc-devel] TStringField, String and UnicodeString and UTF8String

[LacaK]

>   
>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110114/d08dc202/attachment.html>