On Thu, 2011-01-13 at 09:49 +0100, LacaK wrote: > 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... > 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. 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. Joost. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
