>I am assuming here that the fields that will form the PK cannot be changed (similar to the surrogate key, they would be computer generated). What other problems are there related to using the combination of fields rather than a surrogate field.
>
>Using my example of version/revision numbering - I have got to make sure that no duplicates exist or any revisions omitted - if I went from V1.00A to V1.00C the auditor would want to know where V1.00B was - so all of this has got to be coded. What benefit does a separate surrogate field give me ?
>
>If you were going to allow for operator error in entering numbers, another question an auditor might ask is why record refered to by key #12345 refered to V1.00A of document X at one point and later refers to V2.34D of document Y, because you've allowed correction of the version/revision numbers. Either system seems to have inherent problems if you allow modification of the important fields.
>

Paul,

Your argument assumes that you would show the surrogate key to someone. The Primary Key is Strictly a relational database integrity issue for the computer and the computer alone.

You might still have a version/revision numbering sequence and the auditor would be interested in gaps in that sequence. But the auditor and everyone else nevers sees the integer that teh computer uses to match records between tables (which is the sole responsibility of a primary key). Why have both? Because computers are much faster at seeking data on an integer than they are on an expression, in fact they are faster on intergers than they are on any other single field data type.