|Subject||Re: [IBO] Is CURRENCY field column attributes ignored?|
> But I jast want to say that currency is mainly usefulThe issue is with the Delphi currency type - it is fixed at 4 decimal
> 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.
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
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
> Moreover, I'm surprised that even with a 15,2 definition,Exactly, this is a known issue. Until IB6 the declared precision was
> 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.
not even stored at all. Now it is stored but is not enforced.
> So since Delphi Currency is already a INT64, what will happendThat depends on the declared scale. Remember that the integer scaling
> if we send it's memory image to Interbase directly?
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 theI just took a look at the source for IBX (its an out of date copy but
> way it works.
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
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