>I'm converting an old invoicing application where primary keys are defined by the user when adding new records. For example, key "PACBELL" might be used to add new vendor "Pacific Bell", etc. For most accounting-type application, this approach seems to be the norm for fast data entry.
>
>In my new development I use integer-based surrogate keys but I'm thinking I might have problems with existing users who are accustomed to entering memorized vendor keys in data entry which is easier than either entering in the unfamiliar new surrogate key value or using the separate lookup form.
>
>I could keep the existing key as candidate key and use it for data entry but it's slightly more work and I feel it's really unnecessary to keep both.
>
>Any suggestions?

John,

I agree with Craig. And while using surrogate keys has saved me many headaches, most users hate them. They'd much rather think of their account as PACBELL than 39765. So don't show them the Primary Key, only their own lookup code. It's well worth the little bit of extra effort to keep your users from thinking #@%$^ programmer every time they look at the form.

David.