<!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:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">Please, be patient. I'm working on it, as you can see in the bug reports
and commits.
</pre>
</blockquote>
ok, of course<br>
I did not know your plans, ideas, thoughts etc.<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
As I said earlier, widestringfields aren't available in fpc yet. Someone
wrote some code for it, but it is never properly tested and probably
only worked by accident.
</pre>
</blockquote>
I did not know that, I was thinking about TWideStringFields as a
implemented, supported thing<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
But I don't commit everything in one go, it's work-in-progress. And I
need to write tests for everything that I commit. You mixed two things
in one patch, so I had to split it into pieces.
</pre>
</blockquote>
ok<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
I did some tests with different Delphi versions, with and without
unicode. And beside finding some bugs in XE's string-db code I think I
know a solution for all problems regarding strings and unicode.
But let me thing it out, write tests, write code and test if it works
indeed.
</pre>
</blockquote>
ok<br>
if you can inform about your plans, order of tasks etc. ... it will be
welcomed<br>
if I can help you, let me know ... for example I have fix for
TODBCConnection.SetParameters ... there is missing ftTime and
ftWideString,ftWideFixedChar cases ... as revealed by testing with
ODBC/MySQL<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">IMHO root of problem is in different definition of TFieldDef.Size and
TField.Size
Documentation says, that
1. TFieldDef.Size should be "For string and byte fields, Size is the
number of bytes reserved "
[?]<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>
</pre>
</blockquote>
<pre wrap=""><!---->
I don't care what the documentation of others say. It is about how we
implemented it and how we document things.
</pre>
</blockquote>
ok<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
I've read the documentation and did some tests. The documentation is
simply wrong here. The behavior changed with different versions of
Delphi, the documentation is never adapted.
As I wrote in the bug-report, TFieldDef.Size should contain the number
of bytes to hold the string, without the leading 0.
</pre>
</blockquote>
why do you think so ?<br>
If we do not care about Delphi documentation, it seems to me more
consistent, that TFieldDef.Size and TField.Size says about equal things<br>
(this is similar story as TField.AsBCD: TBCD and TParam.AsBCD: Currency
... same name, different meaning ... in my opinion something very
strange)<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
Note that with the unicode-versions of Delphi have in TFieldDef.Size the
amount of characters * 4 in TFieldDef.Size. For WideStrings and normal
strings.
I'm thinking about adding a property to T(Buf)Dataset in which you can
specify if you want to use unicode-length strings, or 'normal' lengths.
So that we can add backwards-compatilibity, which Delphi doesn't.
</pre>
</blockquote>
would not be better add such property to TSQLConnection class, as IMO
all SQLQueries connected to one DB will work with same type of strings.
So users can set it once and not for every TCustomSQLQuery object
individualy ?<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">2. TField.Size should be "the maximum number of characters in the
string" (for ftString and I guess that also for ftWideString)
[?]<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/en/DB.TField.Size">http://docwiki.embarcadero.com/VCL/en/DB.TField.Size</a>
[?]<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/en/DB.TStringField.Size">http://docwiki.embarcadero.com/VCL/en/DB.TStringField.Size</a>
</pre>
</blockquote>
<pre wrap=""><!---->
That's simply true. Also for widestrings. (tested)
</pre>
<blockquote type="cite">
<pre wrap="">And now let's go look into fields.inc:
1. Function TFieldDef.CreateField copies Result.Size:=FSize (so
TField.Size:=TFieldDef.Size)
2. function TStringField.GetDataSize returns for ftString ... Size+1
3. function TWideStringField.GetDataSize returns for ftWideString ...
(Size + 1) * 2
</pre>
</blockquote>
<pre wrap=""><!---->
Those functions have to be adapted, yes. I have the changes here but I
need to fine-tune the tests, clean up etc.
</pre>
<blockquote type="cite">
<pre wrap="">So also here we can see, that FieldDef.Size is expected to be number
of characters not bytes.
</pre>
</blockquote>
<pre wrap=""><!---->
This was the case in the past. And it didn't lead to problems as
widestrings were never used properly. (That's why no-one bothered how it
was implemented for widestrings)
</pre>
<blockquote type="cite">
<pre wrap="">So IMHO logical conclusion will be say, that TFieldDef.Size for string
fields has same menaing as Field.Size, so it is number of characters
(so documentation is wrong in this case ... also fast test in Delphi
shows, that FieldDef.Size=Field.Size=number of characters)
</pre>
</blockquote>
<pre wrap=""><!---->
No, our implementation is wrong and we have to adapt our code. That way
it is also possible to fix the unicode-problems you've reported.
ps: if you want to know what the Delphi-XE-bug is. when using the
TClientDataset, for widestrings, TFieldDef.Size is four times the amount
of characters (ok), but when you get TWideSTringField.Datasize the
answer is two times TfieldDef.Size +2.</pre>
</blockquote>
Yes same as in FPC GetDataSize:=(Size+1)*2<br>
<br>
<blockquote cite="mid:1298544139.11528.29.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> So if you have a wide-string of
40 characters. TFieldDef.Size is 160, but TField.Datasize 322.
(obviously wrong)
</pre>
</blockquote>
Yes, TField.Size = TFieldDef.Size, TField.DataSize = (TField.Size+1)*2<br>
<br>
Laco.<br>
<br>
</body>
</html>