[fpc-devel] TFieldDef.Size vs TField.Size

[LacaK]

> Please, be patient. I'm working on it, as you can see in the bug reports
> and commits.
>   
ok, of course
I did not know your plans, ideas, thoughts etc.

> 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.
>   
I did not know that, I was thinking about TWideStringFields as a 
implemented, supported thing

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

> 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. 
>   
ok
if you can inform about your plans, order of tasks etc. ... it will be 
welcomed
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

>   
>> 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 " 
>> [?]http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size
>>     
>
> I don't care what the documentation of others say. It is about how we
> implemented it and how we document things. 
>   
ok
> 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.
>   
why do you think so ?
If we do not care about Delphi documentation, it seems to me more 
consistent, that TFieldDef.Size and TField.Size says about equal things
(this is similar story as TField.AsBCD: TBCD and TParam.AsBCD: Currency 
... same name, different meaning ... in my opinion something very strange)

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

>   
>> 2. TField.Size should be "the maximum number of characters in the
>> string" (for ftString and I guess that also for ftWideString)
>> [?]http://docwiki.embarcadero.com/VCL/en/DB.TField.Size
>> [?]http://docwiki.embarcadero.com/VCL/en/DB.TStringField.Size
>>     
>
> That's simply true. Also for widestrings. (tested)
>
>   
>> 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
>>     
>
> Those functions have to be adapted, yes. I have the changes here but I
> need to fine-tune the tests, clean up etc. 
>
>   
>> So also here we can see, that FieldDef.Size is expected to be number
>> of characters not bytes.
>>     
>
> 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)
>
>   
>> 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)
>>     
>
> 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.
Yes same as in FPC GetDataSize:=(Size+1)*2

>  So if you have a wide-string of
> 40 characters. TFieldDef.Size is 160, but TField.Datasize 322.
> (obviously wrong)
>
>   
Yes, TField.Size = TFieldDef.Size, TField.DataSize = (TField.Size+1)*2

Laco.

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