> But QuickDesk or IBConsole do not allow that. I've
> entered values with IBO that did a "conversion error"
> in IBConsole and QuickDesk when I've tried to read
> that record. IN QuickDesk I was able to put another
> value in the field, in IBConsole I was not, since the
> record was not displayed after the error.

IBConsole and QuickDesk are not generic development libraries with
complicated "live" queries and performance implications to consider.
They can afford to make special efforts in regard to precision
restrictions, as you will probably not see the impact. Try doing this
on a more generic basis and the impacts will probably be more
noticeable. (Disclaimer: I am guestimating, I have not tested any
such implementation to see how it goes. Perhaps Jason would have a
better idea.)

> The "offending" code is:
>
> SQL_INT64,
> SQL_INT64_: begin
> for ii := 1 to -SQLScale do tmpVal := tmpVal * 10;
>
> So you can see that the field value, if you have scale 2,
> is multiplied by 100 before assignment. So if Delphi
> currency max is, for instance, 1000,99 and current value
> is 200,12, here the value is:
> 200,12 * 100 = 20000,12 ----> overflow.
> I've had a look at IBX code and they directly assign the
> "memory" image of the currency (already scaled to INT64)
> to the buffer, as long as I can understand.

IB/FB does not have a "currency" type. A domain/field of
NUMERIC(18,4) should be equivalent I guess, whereas IBO is attempting
to resolve scale on a more generic basis. Sounds like the particular
code needs some more work.

> BTW, is there a easy way to copy the contents of the
> Delphi stack window?

Not that I have found in Delphi5.

> But the beauty of currency is that they have perfect
> precision of decimals, since they are stored as scaled
> integer (INT64). Apart of Currency attribute, the storage
> from IB_Text (or my IB_Currency) to interbase field
> should not pass through any Float conversions as far
> as I understand.

The IBO currency attribute is simply a control over the default
display text. You can use AsCurrency (Delphi datatype currency)
property against any of the numeric types - and obviously it is
appropriate to do so against any scaled value. You dont need the IBO
currency attribute to be able to use the AsCurrency property.

The use of float routines against scaled integers has concerned me as
well. However the routines used in IBO implement floats as "extended"
which generally reduces the risks involved - with only potential
problems at the very extreme ranges.

Also, there is the legacy issue to be considered. Prior to IB6 (and
even in databases upgraded to IB6 I think) the numeric types over a
precision of 9 were stored as doubles anyway - so IBO was being
consistent.

Remember that the Delphi currency type has a fixed scale of 4, whereas
IB/FB scaled integers have no such restrictions. So IBO must be
prepared to make the appropriate conversions. The ideal situation
would be for someone to implement a scaled integer class that can cope
directly with the values from the database. Any volunteers :-)


Anyway, I think you have highlighted the offending code.

Jason, are you already dealing with this? Did you want me to take a
look?

Geoff Worboys
Telesis Computing