David,

Thanks for the response.

>Treat deleted records just like you would in SQL Server and you'll be in much better shape when you move there later. In other words, don't try to re-use the deleted records, but instead run with SET DELETED ON and get rid of them in the VFP cursor that updates the VFP table.

Understood. I don't think the problem will be in the re-use, but in adding a new record that happens to have the same key as a deleted record (see below).

>Is there any good reason to do that (other than to re-use a record in a DBF?) Are your VFP tables free or in DBC? Primary key defined as such or not? Unless you have an extremely compelling reason to re-use keys, just delete 'em and avoid the hassle.

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. In SQL Server, the record would have truly been deleted and this would not be an issue at all. Packing the table after each deletion is not a realistic solution, given the possible performance overhead. See what I'm getting at?

Laterness,
Jon