Globals are a single named storage spot independent of a Record, so it is NOT repeated. You set a Global by the Storage Tab.
If you Currency Rate is just one value and not changing, then a Global is a good choice.
If you have various Currencies, varing times, or your calculations using that Rate need to be fixed in time...
I would create a table of Currencies, the rate and when you captured that rate. Link your calculations to that Rate Table by a relationship.
You still can have many calculation using a single Currenct Rate, kinda like a global.
And look out for differences in how global fields behave if you have multiple users accessing the database via a network. Changes made to a global field will not persist after a user closes the file unless they opened the file on the host computer. And changes made to a global field by one user will not be visible to other users who have the database open at the same time. It's like each user has their own personal copy of any global fields.
This can be very useful, but if you want to pull a conversion rate off the web and have it be accessible to all users, you may need to put that value in a nonglobal field in it's own table and then link it using the X operator instead of = to each table occurrence where you need access to the exchange rate.
Wow. I never thought of using a separate table. So I could make a new record every day. Would date work as a key field? How would I relate it to my inventory which has no dates in it?
The x operator: is that a Cartesian join?
Why would you need more than a single record?
How exactly do you intend to use the currency conversion factor?
I was working from the assumption that this table would have a single record and thus you could use the cartesian join operator (x) so that it will match to all records in any table where you choose to link in this table.
You're right. A single record would be fine.
It is hard to say from what you describe so far, how many and what type Currency Records need.
Record for Yen to Dollars
Record for Pesos to Dollars.
Maybe.. you need to fix a Bid... then you would have to save the conversion with the bid.
Maybe.. you need a historical change... then you could chart the records of Yen....
All calculations would update unless you do a Lookup on the factor or other fixed methods.
So I'm hoping Ill be able to link the sterling to euro field in the sterling to euro table to inventory::sterling to euro field Then inventory::Euro price will be a calculation: sterling price x sterling to euro::sterling to euro.
Do you need this value at time of sale on an invoice or are you attempting to compute the total value of your current inventory in both lbs sterling and in euros?
The value of the needed conversion factor will change continuously for your total inventory value, but needs to be locked to the current value at the moment a sales transaction results in funds changing hands. The second option typically requires copying the needed conversion factor into a number fields so that future fluctuations do not change the value for this specific sales transaction.