Hi Don,

OK, a little terminology check :-)

If you require a key from one table into another table, then it's a foreign key for the first table, not a primary key.

As to the unique code versus the primary key, there's nothing wrong with that as long as all "behind the scenes" referential integrity is done via the keys and you have some mechanism to ensure that the codes are unique. IAC, with an accounting system, you need to have these code. For example, a ledger account number will be a unique code but not necessarily a key. However, if at some point you change the account number in the chart of accounts, all transactions should remain booked to that account ... this will be accomplished if you are using the keys and not the unique code. See?


>I am in the process of introducing the concept of primary keys to my data structures. I do not use databases at all. I will make use of a separate file to pull the keys from. My question is this ...
>
>When I build files containing things which require unique keys, such as something like EXPENSE CATEGORIES in an accounting system, I usually have a unique code associated with a description (i.e. AUTO - Automobile Expense, etc ...). This is so ingrained into my thinking that recently when I began using Primary Keys, I had a file in which I inserted both a Primary Key AND the unique code which is associated with the description.
>
>This seems redundant but before I take the leap and get rid of the unique code I would like some sort of supportive statements from this forum confirming that this is in fact the way to go or alerting me to some pitfalls to this path. Any comments ?