Sean,

<< Use a TCurrencyField - you won't regret it. >>

TCurrencyField is the same thing as a TFloatField.  Only the TBCDField will
use the Delphi Currency type and not encounter rounding errors.  Usually the
maximum scale of 4 decimal places for the Currency type is plenty to handle
any Currency calculations.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Sean,
>
> << Use a TCurrencyField - you won't regret it. >>
>
> TCurrencyField is the same thing as a TFloatField.  Only the TBCDField will
> use the Delphi Currency type and not encounter rounding errors.  Usually the
> maximum scale of 4 decimal places for the Currency type is plenty to handle
> any Currency calculations.
>
Tim,

You are almost correct and I was obviuosly wrong in my assumption that
TCurrencyField buffers or stores its data as a Currency value. If you
look in DB.PAS, TCurrencyField descends from TFloatField and differs in
the constructor. A TCurrencyField has a field type of ftCurrency which
controls how the data is formatted for display in a grid or edit control
(see TFloatField.GetText). I am surprised that borland did not change
the .Value and .AsVariant properties to return a currency type, but
perhaps they wanted to maintain backwards compatibility since D1 had no
currency type (don't know when it was introduced). Also may be that most
databases store currency / money as a formatted floating point.

When I read currency field values I tend to avoid using .Value and
..AsVariant. I use .AsCurrency out of habit so I haven't had problems.
For me the key is to always read or write into a Currency type variable
to get a value with no "approximation error". I think "approximation
error" is probably better term than rounding error for this discussion
since I'll use it to refer only to the fact that the binary fraction in
a floating point value is sometimes only an approximation of a decimal
value. Approximation error comes into play when formatting a result for
display and should rarely if ever concern computational accuracy for
currency values. A currency type has 19-20 significant digits, double
precision has 15-16. Both should be plenty for storing real life money
values. Rounding error is actually *more* likely to happen when
performing cumulative calculations on a currency type than a double
precision floating point type because the result will be rounded to the
precision of the variable type each step of the calculation. It really
depends on what kind of values you are using in your calculations. If
you routinely divide by any number or multiply by fractions that have
lots of precision past a decimal point and do this in multiple steps you
need to make sure you are not losing accuracy because of cumulative
rounding errors.

What it boils down to is that there is no right or wrong ways to store
currency values. No matter what field type one uses it is critical for
the programmer to be mindful of all the issues when dealing with
currency (and actually any numeric types). Namely computational accuracy
including rounding errors, validation before storage, and binary
fraction approximation which relates to display formatting issues.

For money, my preference remains ftCurrency / TCurrencyField since
grids, data aware controls, and third party tools like report engines
can recognize that the value represents a currency value and can
therefore properly format the value for display without my intervention.


Sean

Tim


I can't seem to find a currency type in EDB

Roy Lambert

Roy,

<< I can't seem to find a currency type in EDB >>

DECIMAL is the type that you want.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sean,

<< When I read currency field values I tend to avoid using .Value and
..AsVariant. I use .AsCurrency out of habit so I haven't had problems. >>

True, that may remove any issues by always dealing with the values as the
Currency type.

--
Tim Young
Elevate Software
www.elevatesoft.com