> In my opinion locale should not affect what gets stored in the data
> base and local should not change the meaning of the data. So using
> the locale for currency symbol naively can be problematic. What you
> need to do to really support money in different currencies is keep
> track of your hourly exchange rates etc. Then store your data in
> one currency as a DECIMAL or whatever. Alternatively, store the pair
> (value DECIMAL, currency CHAR(3)) in the data base, with currency
> being the ISO 3-letter code. Be aware of the difference in semantics!
The latter is IMHO the better. If you have a foreign currency
account, it's balance will not raise and fall as exchange
rates change. That's what they are good for. Only at the
time, you transfer money between different currency accounts,
the actual exchange rate is used.
Keeping track of hourly/dayly exchange rates is only good if
you need reports for controlling purposes. There it's better
to have anything converted into your inhouse currency. View's
do a wonderful job here.
BTW: The non-floating-point restriction does NOT apply to
controlling systems, because they are management information
systems and not subject to the Ministry of Finance, as the
bookkeeping data is.
For those who wonder: between 1980 and 1983 I learned, and
until 1987 I worked as a bank clerk. That left some traces
that sometimes are useful.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #