I mean that it's not required to return to old record, recall it and change primary key. I don't mean that it's not doable, it's not required. Normally, file size will be the only difference and pretty much irrelevant one, as long as you can PACK tables on some scheduled basis. To be precise, when developer leaves a project, users used to forget and never PACK, and it still will work for years with no significant performance penalty. To be specific, some reports can slow down a bit, but interface should work always the same way.

>Hi Edward,
>
>Thanks for the reply.
>
>Can you clarify a bit for me. I have a primary key field that is intger. What do you mean by never return to old deleted records? Would the only issue to having a lot of deleted records is file size and or the file defragmentation of adding lots of records ?
>
>Thanks
>
>
>>Just one thing...
>>Normally, every record should have primary key field filled with surrogate (sequential) value, i.e. you create a record and system generates new key for you etc., and you never return to old deleted records. They are gone. It should be irrelevant to system performance how many deleted records are inside.
>>
>>>Hi Rick,
>>>
>>>Thanks again for the reply.
>>>That's kinda what I worked out while I was off line. Thanks for validating my idea on that...
>>>
>>>

>>>SET ORDER TO DelRec IN MyTable
>>>SET DELETED OFF
>>>IF SEEK(.T., "MyTable"
>>>  RECALL
>>>  REPLACE Field1 WITH NewData, ;
>>>    ...
>>>ELSE
>>>  INSERT INTO MyTable;
>>>    (Field1, ...);
>>>    VALUES(NewData, ...)
>>>ENDIF
>>>= TABLEUPDATE(.T., .T., "MyTable"
>>>SET DELETED ON
>>>...
>>>
>>>

>>>
>>>Did I miss anything???
>>>
>>>Thanks
>>>>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?