>I never thought of having a key that wasn't visable. But that is a good point. Then I don't have to worry about what happens if they change the client id. How would I go about generating this integer id, then? With the client ID, the user typed it in so all I had to worry about was making sure it didn't exist already. I'm not sure how to generate unique keys for all my tables.
>
>Views seem to be the way to go. I think that was the unanimous answer.
>
>I remember the text mentioning parameters in views. I'll have to look at that more thouroughly. As to navigation buttons, I can see why they would be useless in a large table, but they're not bad for some of the smaller tables.
>
>I don't know anything about client-servers. We're able to just use the table in its entirety with no problems.
>

The best way to generate unique keys is to have a small table with a key name and a current value. For instance if you have a client table, in the id table the key would be CLIENT and the value might be 10 or something.

You create a stored procedure called NewID and it takes a key as the parameter.
The stored procedure then locates the correct key record, locks the record, gets the current value, does a replace value with value + 1 and returns the value retrieved after unlocking the record. This way, only one person at a time can increment the number.

In your Database container you modify the table and for this key field, say clientkey, you set the default to be NewID('CLIENT'). Anytime you append a new record to the table, the default value will automatically fill in. If you have a table that already exists, add the clientkey and the do a replace all clientkey with NewID('CLIENT') and you will create all the unique keys.