At 12:24 AM 20-06-02 +0000, you wrote:

>In initially designing the script to create the FB/IB6 Dialect 3
>(I needed TIME and TIMESTAMP) I intentionally avoided using
>DOUBLE PRECISION type since the LANGREF indicated that the storage
>for this was usually 64 bits - platform dependent and something
>I wanted to avoid (I thought because of my D3)...

While there might be a D3 issue related to the bounds of range for fp
numbers (which I don't know, as I no longer have D3 on my system) I think
your problems may have more to do with the way numbers are stored in
Dialect 3. You might like to pick up Geoff's paper on the subject of
scaled numerics from the TechInfo page for at least some insight into how
the precision of numbers affects the storage type.

In moving from desktop to C/s databases, there is undoubtedly some review
needed of the numerical types. Paradox forces you to use floats even when
they are not suitable for your purpose, because it doesn't supply exact
numerics. At best, you have a 32-bit integer to which your client code can
apply exponential factors to arrive at the precision you need for exact
numerics.

In choosing number types, Ann Harrison (the goddess of InterBase) often
touts the rule of thumb "Use floats for things you measure, use exact
numerics for things you count". There's still a *lot* of confusion around
about precision with Dialect 3 numbers and, as you rightly point out, the
Borland documentation provides little help for people moving from a
different "numerical universe".

See what you can conclude from Geoff's paper and, by all means, raise
questions in the ib-support list. Questions about scale and precision very
often do press Ann's button and she is about the best person to put you
straight about InterBase/Firebird numerics. Unfortunately, Ann doesn't
work with Pascal at all. Still, there are other contributors there who
have been down the numbers road with Delphi; alternatively, a good place
to get answers about Delphi 3's numerical limitations might be one of the
borland.delphi newsgroups.

>It turns out that the resolution of my 'invalid floating point'
>problem was to recreate-repump my database, but this time creating
>and using the DOUBLE PRECISION instead of the Numeric(18,8) or the
>Decimal(18,8).
>
>I suppose that someone, somewhere, somehow might be able to make
>clear for all times exactly where all the external and internal
>conversion issues related to this problem, might lie, and then
>again, maybe it's only 'classic' D3 users like me <g> who really
>suffer from the varieties of this issue...but then maybe not.

It's possible that getting D3 to accept your numbers without complaint
won't be the catch-all solution to your floating point problems, if
accuracy is your ultimate objective. I was a Paradox developer before I
entered the C/S universe and, in fact, used floats only rarely, for
precision reasons. When Borland introduced the binary coded decimal (BCD)
"pseudo-type" one could use the Paradox Numeric type for money fields with
a little more confidence; but I still don't trust floating point types for
storing financial data, especially data that are going to be transmogrified
by multiplication, division or exponentiation.

In summary, you just have to be darned careful with numbers!


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com