> But I jast want to say that currency is mainly useful
> for monetary values, so for Usa ($) and Europe (Euro)
> it's paramount using it with a 2 digit scale (i.e.
> (15,2) or (18,2)). Having onli a ,4 managed as
> INT64 is a bad thing.

The issue is with the Delphi currency type - it is fixed at 4 decimal
places. This means that (18,2) can overflow the value of the currency
datatype. The ONLY option is to either avoid the delphi currency type
OR restrict the input in to the database field to avoid overflow
problems.

You could declare NUMERIC(16,2) to match delphi currency type
capability, but IB does not properly implement precision, so you still
need to restrict the input values with a check as shown in my previous
posting.

> Moreover, I'm surprised that even with a 15,2 definition,
> using IBO and it's "bug" lets me store very huge numbers.
> Seems that Interbase does not make any check by itself,
> it only stores the value as INT64.

Exactly, this is a known issue. Until IB6 the declared precision was
not even stored at all. Now it is stored but is not enforced.

> So since Delphi Currency is already a INT64, what will happend
> if we send it's memory image to Interbase directly?

That depends on the declared scale. Remember that the integer scaling
is not part of the data (as it is with floating point), the scale is
simply part of the type definition. The data is a pure integer value.
So the IBO code does need to match the scales between the field and
currency type in order to reflect the correct value (otherwise you
will be a factor of 100 out).

> could worth investigate. Having a look to IBX code semms the
> way it works.

I just took a look at the source for IBX (its an out of date copy but
I presume it is still close). IBX does provide scaling adjustments
for currency data type (see IBSQL.pas). It also appears to have
restrictions over what values it will permit to be translated to
currency (scale >= 4) otherwise it uses double!!! (see IBCustomDataSet
.pas).

I have not bothered to track exactly what that code was about, but I
assume it is IBX's way of avoiding the overflow possibilities that we
are discussing. Personally I prefer the overflow problem and know
that I am still dealing with an exact value, rather than have the code
change the data type in this manner.

My 2c would be to not use IBX as an example of how things should be
done :-)


Geoff Worboys
Telesis Computing