<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=x-mac-ce" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:1294927587.9323.33.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">So IMHO there must be:
1. allocated space in record buffer in size 4*TFieldDef.Size+1
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">2. redefine meaning of Size property (as number of bytes not
characters) and create fielddefs with Size*4
</pre>
</blockquote>
<pre wrap=""><!---->
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...
</pre>
</blockquote>
I see here these possible problems/disadvantages:<br>
1. In many cases (dynamic build or ad-hoc queries) is creating
persistent fields not very effective (or complicated)<br>
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<br>
3. in TStringField is Size used also to determine default DisplayWidth
(for TDBGrid) and in Delphi also for setting MaxLength in TDBEdit<br>
(so here we can see, that Size is used like max.number of characters
rather than bytes)<br>
4. incompatibility of Delphi (if we reclasiffy Size as number of bytes
not characters)<br>
<br>
So I would prefer 1st way (increase buffer size, may be if we will
support only BMP then 3*Size+1 will be sufficient)<br>
So Size remains as "character length"<br>
<br>
<blockquote cite="mid:1294927587.9323.33.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">hm, according to
<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size">http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size</a> is Size
number of characters
but according to
<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size">http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size</a> is Size number
of bytes in underlaying database
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, that's indeed the problem. But there's also the .DataSize property,
so we could use that.
</pre>
</blockquote>
Yes, but DataSize is defined only in TField not in TFieldDef class<br>
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)<br>
<br>
<blockquote cite="mid:1294927587.9323.33.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">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.)
</pre>
<blockquote type="cite">
<pre wrap="">but TField is created from TFieldDef and
TField.Size=TFieldDef.Size ... so isn't it curious ?
</pre>
<blockquote type="cite">
<pre wrap="">Not that when you want to use UTF-16 (or 32) you have to use
TWideStringFields.
</pre>
</blockquote>
<pre wrap="">So TWideStringField is "no-encoding-agnostic" field (is it designed to
be everytime UTF-16 encoded) ?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Yes I understand now.<br>
<br>
Laco.<br>
<br>
</body>
</html>