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

[LacaK]

> I'm adding some ftTime tests.
Did you noticed, that I already posted such tests 
http://bugs.freepascal.org/view.php?id=18763 ?
Then let me know, I send you fix for ftTime for TODBCConnection ... but 
depends on http://bugs.freepascal.org/view.php?id=18773

>  All widestring-issues are postponed until
> I found a way to deal with them, unicode, and have tests to test them.
>   
ok

> but now the TFmtBcd field is finally implemented,
please look at http://bugs.freepascal.org/view.php?id=18809
and IMO also this bugs must be solved first to continue with 
implementing TFmtBcdField into connectors
http://bugs.freepascal.org/view.php?id=18388 and 
http://bugs.freepascal.org/view.php?id=18807

>  you can add support
> for that? Now it only works with sqlite,
yes, but there is missing support for parameter ftFmtBCD in Procedure 
TSQLite3Cursor.bindparams

>  maybe you can add it for the
> other databases that you use? (odbc,mysql?)
>   
yes i can do it, but would wait for fixing above mentioned bugs, to not 
touch code twice if something in fmtbcd unit changes

>   
>>> 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
>>     
>
> It depends on how they are used. I think it is very usefull for a
> programmer to know the maximum amount of characters. (TField.Size) 
yes

> And a
> programmer should be able to detect how many bytes are reserverd to
> store it (TFieldDef.Size). 
>   
yes, but I would preffer introduce new TFieldDef.DataSize property, 
which will serve for "byte length".
So we will have TFieldDef.Size, TField.Size="character length" and 
TFieldDef.DataSize, TField.DataSize="byte length"
Then we will be able use TFieldDef.DataSize instead of 
TCustomBufDataset.GetFieldSize (we can completely drop this) and all 
fields stuff will be in one unit fields.inc

> This is especially important if we are supporting unicode-strings, where
> both values can differ.
yes
>  So when you are getting/setting data from the
> server, you use TFieldDef.Size, and then you want to check what the
> maximum amount of characters is, TField.Size.
>   
yes, my only objection is, that same name is used for different things, 
which is confusing, non-intuitive and will/can lead to "misunderstandings"

>   
>>> 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 ?
>>     
>
> Maybe. but I have to think about it better. Because if code in
> fields.inc depends on it, we have to add the property to TDataset
> itself.
>
>   
yes I also must think about it more

>>> 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
>>     
>
> There are more ways to solve that. And we need to find how the Delphi
> datasets which do not have this problem do that.
>
> One way is: TField.Size := (TFieldDef.Size div 2) if it's a WideString,
> and div 4 if unicode is enabled.
>  Or the TDataset descendant has to
> correct the value for WideStrings when creating fields. (How?)
>
>   
hm, we must think about it more

Laco.

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