<!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:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
I'm adding some ftTime tests.</pre>
</blockquote>
Did you noticed, that I already posted such tests
<a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=18763">http://bugs.freepascal.org/view.php?id=18763</a> ?<br>
Then let me know, I send you fix for ftTime for TODBCConnection ... but
depends on <a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=18773">http://bugs.freepascal.org/view.php?id=18773</a><br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> All widestring-issues are postponed until
I found a way to deal with them, unicode, and have tests to test them.
</pre>
</blockquote>
ok<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
but now the TFmtBcd field is finally implemented,</pre>
</blockquote>
please look at <a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=18809">http://bugs.freepascal.org/view.php?id=18809</a><br>
and IMO also this bugs must be solved first to continue with
implementing TFmtBcdField into connectors<br>
<a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=18388">http://bugs.freepascal.org/view.php?id=18388</a> and
<a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=18807">http://bugs.freepascal.org/view.php?id=18807</a><br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> you can add support
for that? Now it only works with sqlite,</pre>
</blockquote>
yes, but there is missing support for parameter ftFmtBCD in Procedure
TSQLite3Cursor.bindparams<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> maybe you can add it for the
other databases that you use? (odbc,mysql?)
</pre>
</blockquote>
yes i can do it, but would wait for fixing above mentioned bugs, to not
touch code twice if something in fmtbcd unit changes<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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) </pre>
</blockquote>
yes<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">And a
programmer should be able to detect how many bytes are reserverd to
store it (TFieldDef.Size).
</pre>
</blockquote>
yes, but I would preffer introduce new TFieldDef.DataSize property,
which will serve for "byte length".<br>
So we will have TFieldDef.Size, TField.Size="character length" and
TFieldDef.DataSize, TField.DataSize="byte length"<br>
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<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">This is especially important if we are supporting unicode-strings, where
both values can differ.</pre>
</blockquote>
yes<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
yes, my only objection is, that same name is used for different things,
which is confusing, non-intuitive and will/can lead to
"misunderstandings"<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote 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>
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
yes I also must think about it more<br>
<br>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote 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>
<pre wrap="">Yes, TField.Size = TFieldDef.Size, TField.DataSize = (TField.Size+1)*2
</pre>
</blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
<blockquote cite="mid:1298555700.11528.41.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap=""> Or the TDataset descendant has to
correct the value for WideStrings when creating fields. (How?)
</pre>
</blockquote>
hm, we must think about it more<br>
<br>
Laco.<br>
<br>
</body>
</html>