>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.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only