Hi Jim,

I'm sure you know this, but in the bigger VFP picture, being consistent with surrogates also helps you design better classes. For example, in one of my frameworks, I have a data entry form with an AddRow method. The Form also has a MainTable property that stores the ALIAS() of the primary table for that Form. I have the following code there (oDS = a Data Services Custom object):

cMainTable=ThisForm.MainTable
cPK = oDS.GenPrimaryKey
IF cPK # "ERR"
   INSERT INTO (cMainTable) (pk) VALUES (cPK)
ENDIF

No mess, no fuss and works like a champ.

>Using a surrogate key here solves the problem. I am also a proponent of keeping it simple. Surrogate keys are always a single field, simple. If I use a surrogate key in one place I want to use them everywhere, consistency is simple.
>
>So, my conclusion, forget the natural keys and use surrogate keys everywhere whehter one thinks they need it or not. Every table in every database will be the same design as far as the PK goes.
>
>Another plus of surrogate keys, there is never any need to go beyond Boyce-Codd NF. After 3rd NF, insure 3rd NF for any feasible candidate keys in the table and you're done. No need to even think about 4th and 5th NF's since they only apply to multifield PKs.