One basic rule that many developer use is: you shouldn't base your primary key on a field that the user can see. You can still use a surrogate primary key and create a candidate index on the customer ID field if you want to make sure that it will be unique. To avoid the problem you got when deleting and recreating the same ID, create a candidate index like this:

INDEX ON CustID TAG CustID FOR NOT Deleted() CANDIDATE

You don't have to reset the record source of a grid after packing a table.

Rushmore won't use an index with a FOR clause. In addition to the candidate index proposed above, create a second regular index on CustID field to have Rushmore kick in.

HTH

>My primary keys are built from real world entity attributes that are supposed to be unique (like a customer ID say). If I create surrogate primary keys, then they don't serve the purpose that I want, which is to keep me from *accidentally* duplicating a customer ID (in that example). Isn't this the dominant purpose for RI code?
>
>In 2.6 I used to pack all the time to avoid this. But if I have, say, a grid whose record source is a table and I pack the table, I have to go back and reset the record source to the grid. This is a pain to do for every grid, column, list, etc. in the entire application that may use that table.
>
>I didn't realize you could put a FOR clause in the key definition. Is that true? It gives me another idea though to use something like
>INDEX ON IIF(DELETED(),,customerID)
>
>Still, I think Rushmore wouldn't honor it....