| Subject | Re: [IBO] 4.2F D5 TiboTable IndexFieldNames TdateField Error |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-11-07T00:24:24Z |
At 05:30 PM 06-11-02 +0100, you wrote:
in TTables and the casting of date variants when the date is null. In
former times when I used TTable components and therefore had cause to use
IndexFieldnames, I "worked around" it by a combination of measures
-- by not having nullable date types on indexed columns
-- by defaulting the value of the date field for inserts
or
-- by simply avoiding the use of date columns in IndexFieldNames
But really, I don't know of a workaround that will always work; and I
haven't used table objects for years.
Where does the problem come from? Well, in Delphi, it is valid to assign
zero to a date field, because Delphi uses a floating point type for
dates. Date zero in Delphi is Dec 30 1899. Delphi doesn't allow a null
date and, when it encounters one, it converts it to zero.
IB does not use floating point for dates - it uses a numeral structure of
two word types: one for the number of days since 18.11.1878 and one for
the number of milliseconds (?) since midnight. (There is more to it than
that, buried in the internals of the server...twos-complement or
bit-manipulation stuff to work out dates before date zero and so on...)
Delphi knows that the InterBase date zero is 18.11.1878 - so, in casting
the date for text display, it shows either date zero or a null date as the
string '18.11.1878' - which I assume you have set with some property to
override the US format '11/18/1878'.
Now, at some point with IB 5.6, the BDE InterBase driver and Delphi got it
right and was able to handle date zero correctly in IndexFieldNames. I
don't think that is the case now (Delphi 6) because Borland have done a lot
of fiddling about with variants for TFields, which was not very successful.
You *could* try using the IndexName property instead of
IndexFieldNames. That will cause Delphi to use your actual IB index and
not attempt to construct its own client-side index from your TDateField,
thus avoiding the double-casting problems.
From your report, it looks as if that old bug might be back; or it might
be that some combination of IBO's date variant handling and the date
variant handling in your version of Delphi is throwing up a condition that
causes this error to occur.
As you see, I really don't have one single answer, even though I recognise
the symptom of a problem I have myself encountered in past times. If you
need to pursue this thread, would you please report which versions of
Delphi and IBO you are using?
Helen
>Hallo,I don't know a solution - but it's an old Delphi problem (bug?) with dates
>when i insert a FieldName (Fieldtype=TdateField) in IndexFieldNames
>i got the following error when i set the table to active.
>'17.11.1858' ist kein gültiger Gleitkommawert.
>in english
>'17.11.1858' is no valid floatingpointvalue.
>All Entries in the table and in the datefields are OK
>and between 1989 and 2009.
>Did anyone know a solution?
in TTables and the casting of date variants when the date is null. In
former times when I used TTable components and therefore had cause to use
IndexFieldnames, I "worked around" it by a combination of measures
-- by not having nullable date types on indexed columns
-- by defaulting the value of the date field for inserts
or
-- by simply avoiding the use of date columns in IndexFieldNames
But really, I don't know of a workaround that will always work; and I
haven't used table objects for years.
Where does the problem come from? Well, in Delphi, it is valid to assign
zero to a date field, because Delphi uses a floating point type for
dates. Date zero in Delphi is Dec 30 1899. Delphi doesn't allow a null
date and, when it encounters one, it converts it to zero.
IB does not use floating point for dates - it uses a numeral structure of
two word types: one for the number of days since 18.11.1878 and one for
the number of milliseconds (?) since midnight. (There is more to it than
that, buried in the internals of the server...twos-complement or
bit-manipulation stuff to work out dates before date zero and so on...)
Delphi knows that the InterBase date zero is 18.11.1878 - so, in casting
the date for text display, it shows either date zero or a null date as the
string '18.11.1878' - which I assume you have set with some property to
override the US format '11/18/1878'.
Now, at some point with IB 5.6, the BDE InterBase driver and Delphi got it
right and was able to handle date zero correctly in IndexFieldNames. I
don't think that is the case now (Delphi 6) because Borland have done a lot
of fiddling about with variants for TFields, which was not very successful.
You *could* try using the IndexName property instead of
IndexFieldNames. That will cause Delphi to use your actual IB index and
not attempt to construct its own client-side index from your TDateField,
thus avoiding the double-casting problems.
From your report, it looks as if that old bug might be back; or it might
be that some combination of IBO's date variant handling and the date
variant handling in your version of Delphi is throwing up a condition that
causes this error to occur.
As you see, I really don't have one single answer, even though I recognise
the symptom of a problem I have myself encountered in past times. If you
need to pursue this thread, would you please report which versions of
Delphi and IBO you are using?
Helen