Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
When to choose currency data type?
Message
De
23/08/2009 11:01:05
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
22/08/2009 08:46:49
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows XP SP2
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01419279
Message ID:
01419943
Vues:
57
>May I ask one further question:
>
>What if I am allowing my user to specify which currency to use everytime when he/she attempts to input an amount in my accounting application, will CURRENCY type helps? i.e. if my program allows multi-currency transactions, in which way, or will currency type field help?

Not in the same field. You need one field for the calculative currency - whichever it is, in which the user's base transactions are done - and one for whichever other currency is the actual, and of course a FK into currencies table. Also not a bad idea to keep the exchange rate in the transaction, for historical reasons and speed. Last time I had to do this I couldn't, because the exchange rates weren't exactly known. It was a reconstruction of a building project, over the years of high inflation, so there were many records with amounts in one currency but not the other, and the other currency was supposed to give some realistic value to the first, so the amounts were entered as found, and the other recalculated once the historic exchange rate for that date was known. When it wasn't, I'd go to the last known date (by having an index on currency code + dtos(date) descending, with Set Near On) and take the rate from there.

Of course, as the values of two currencies fluctuate, you can never get their totals straight, as these would relate to some weighted average across the observed period, not to today's rate. But you can keep totals per currency. Makes for interesting reporting :).

As to whether currency will help, why not - it's 8 bytes per field while holding at least 15 digits (plus dot and sign - that'd be an equivalent of N(17,4)), it's faster if you have to calculate a lot. If that is of no concern, simple numeric can take you to N(19), although that still holds only 15.5 digits - lower ones are zeros. Which should be tested - in those inflation years, it was FP2.0 that we used, maybe precision is better nowadays, which I doubt. The IEEE number format should still be in use - but currency may be more precise... which it is:
x=$1*1e14+2222.2222
?x
x = x - 1e14
?x
This looks like 18 significant digits to me.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform