Hilmar,

>>>A primary key is unique and identifies a specific record. A candidate key is also unique, however it relates to an entity other than the primary key. An example would be a customer code, social security code, etc. If a violation of uniqueness occurs due to a duplicate – the system user must know. It has been known to have duplicate social security numbers issued. When this occurs it must be resolved. Hope you get the general concept.
>>
>>Thomas,
>>
>>PMFJI, but do you mean that if I have a uniquie control number for each record that could be the primary key, but if I also have a business need to make sure the social security number is unique, that would be a candidate? Silly question, I'm sure, but when do you need both? Why not just use the SSN?
>>
>>Renoir
>
>Expanding on Hector's reply, in more general terms, if you want to use keys the user sees for PKs, you have to think seriously, for each and every table, what your PK will be. If you use surrogate keys (autogenerated numbers), you have a universal solution.
>
>Hilmar.

"...you have to think seriously, for each and every table, what your PK will be.". From all of your other posts you sound like a person who does think seriously about most things.

In my opinion it would be the database layout and especially the PKs that deserve (and get, here) the MOST thinking of all.

Walter M. shows extremely admirable persistence on this issue in the face of countless expressions to the contrary, many of them explicitly or implicitly ridiculing his position.
I agree 100% with Walter - thinking is better than proceeding blindly.

regards,

JimN