Hi Jon.

>The tables are in a DBC with primary keys defined. An example would be a table named Banks whose primary key is a 6-character code field that the user defines (e.g. "CITI"). If a user deletes the CITI record, then it gets marked as deleted and that's fine. However, if another user then wants to add CITI back into the table then you will violate the primary key constraint because it already exists, albeit as a deleted record.

That's a very good argument for *not* using user-defined values for primary keys. Instead, use a meaningless auto-assigned key, such as the auto-incrementing integer field added in VFP 8. Then, when the user deletes "CITI", there's nothing stopping them from re-adding "CITI".

Alternatively, if you're stuck with this design, then replace the key value with something unique when the record is deleted, like SYS(2015) (if the field is long enough) or a TRANSFORM() of an auto-assigned value. That way, the original key is nuked and can be reused if necessary.

Doug