w/D3.02, IBO4.Hd, FB/IB Dialect 3:

I presume that not many will encounter my same environmental
conditions, but I need to contribute my experience (or lack of...)

I have, for now, resolved the 'invalid floating point...' errors
I was getting upon attempting to assign fp data to Dialect3
Numeric or Decimal columns from within a D3.02/IBO4.Hd app.

The FB/IB Dialect 3 database in question was created with IB_SQL,
ib_domain.sql, and add'l script...

{ which created columns of first Numeric(18,8), and then recreated
and repumped using Decimal(18,8) to check for improvement: none }

Data was then migrated from Paradox Level 7 tables using a Datapump
obtained from a non-IBO site.

A Delphi 3.02 BDE-to-IBO converted app was then run against this
new FB/IB6 Dialect 3 database with substantial success.

The database and app uses much floating point code and obtains
much floating point data from the FB/IB Dialect 3 database.

Problems began when newly generated data attempted to access
a small permanent table used to store temporary data, and upon
the initial attempts to assign that fp data to the Dialect3
Numeric or Decimal columns, 'invalid floating point...' error
messages were generated.

Debugging IBODataset indicated that the data, while observed in
the buffer (by tooltip debugger) accurately as fp, was intially
accepted into IBODataset as INT64.

Further testing w/FreeIBComponents added to my awareness that my
fp data was trying to store into an apparent INT64 column, which
was created as DECIMAL(18,8).

The Interbase 6 migration guide deals primarily (totally?) with the
migration of <= IB6 to IB6 and discusses some INT64 issues, much of
which are beyond my understanding at this time, but it seems from my
reading of the IB guide that under some conditions is possible for
migrated Numeric or Decimal data to actually be stored as INT64.

My reading of various *interbase* ng postings revealed (to me
anyway..)
that there is indeed some confusion out there on this matter...

However, since D3.02 has no support for INT64, it appears that the
data extracted from my Datapumped-Paradox-Level-7-to-FB/IB6-Dialect-3
database was not in INT64 format when it hit my D3.02 code...

Yet upon attempts to store new data from my D3.02 app into that same
database (different table/same-dtaa-types), I was running into some
variation of an INT64 problem.

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

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.

I have thought that this might also be appropriate to post to
the ib-spport list also, but I am deferring, since I'm new here
and I don't want to risk ruffling... If anyone in clearer
standing than I thinks it appropriate, please copy this to that
list also, since it is most certainly an IB6 Dialect 3 matter also.