> What your entire text lacks here is what particularly is the
> problem. Perhaps it was in a previous message...
>
> I think you are having troubles because Delphi 3 doesn't have
> INT64 support and so I am only able to use the comp type instead,
> which is stored as would an int64 but it is operated upon as if it
> were a float, thus some rounding and precision problems could
> arise. There just may be a bug in there for Delphi 3 that I Could
> root out too if you send me a sample app I'll gladly give it a look.
>

My entire text?
After spending all of that time to try to be so particularly clear?
Oh dear...

This is rather frustrating for me, since there are not a lot
of messages on this board and, in indeed, I did post twice
during the last few days on this, rather specifically, I thought,
...even pasting IBODtataset code to show where the crash occurred...
(one could take a specific line of any of my posts and ask what needs
clarification, also) and, indeed, you asked for a sample app, then
also, and I sent you one, and you replied privately to me that you
had received it...so I'm rather at a loss as to what is going on or
who I am actually communicating with.

>>>>

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

<<<<