Well, if you're here you're a member, but I didn't remember that the message search feature is limited to $Premier members. Sorry 'bout that.

Sure, design for multi-user, but that doesn't mean you can't open the table exclusively sometimes, unless 24x7 is a requirement. If it makes sense for design reasons to prune deleted records instead of recycling them, you could always schedule this for times when the database is not in use.

You asked about maintaining an index on DELETED(). The conventional wisdom is that you want to do this for performance reasons in any case, although there has been some dispute about this too. Anyway, if you're recycling records, then the general idea is to SET DELETED OFF and LOCATE FOR DELETED(). If a deleted record is FOUND() then RECALL it and replace the field contents with the new data, otherwise INSERT a new record.

HTH,
Rick

>Hi Rick,
>
>Thanks for the reply. Unfortunaly I can't search for a thread number as I am not a member of the UT. I guess you can work both sides of the street depending if the app is multi user or not... My current thinking is to make all apps multi user so the need to handle deleted records without opening the table in exclusive...
>
>Thanks
>
>>You'll find lots of opinions on both sides of this question. IMO it's an individual design decision, and different apps will have different requirements. There was an interesting discussion abou this here on UT not too long ago. Look for thread #269678 (Coding, syntax & commands - "What's with the Pack command").
>>
>>>What is the current school of thought on dealing with deleted records?
>>>Seems to me that recycling would be the best bet due to having to open a table exclusive in order to pack it.
>>>
>>>What methods are used to recycle deleted records?
>>>
>>>Do you always have an index on DELETED() so you can SEEK a record then do a REPLACE instead of a INSERT INTO?