>I agree 100% with your approach. I have several applications where the user
>either chooses or assigns a number of some kind (a membership number, or a
>stock code, or an account number) These have NOTHING to do with the primary
>key, which is a unique integer value created by a generator, and which the
>user never sees and cannot mess with.

>Regards
>Tim

Lets's say you had stock transactions to go with your stock code. In the
transaction table, would you use the stock's PK, or the stock code, as a
foreign key in the transaction table?


Regards

Maya