Thank you.

>If it is more than a touch-up, definately do it only if perf problems occur. Do not expect those - if they occur, you probably have a special edge case. But they do exist ;-))
>Break out your code into a module you can reactivate if need arises: for me working on code I already grokked gives a speed boost factor of 3 to 5.
>
>
>>You make a very valid point as far as "the code is long enough in use it should be bug free". But what prompted my question is that I have to re-write the entire routine/code because I am dropping a certain feature (learning from Microsoft :)). And as I re-write this feature I am deciding what to keep and what to drop.
>>Thank you.
>>
>>>The real question - besides simplifying code - is whether keeping the old records in their place on disk will minimize access time (for old HDs, mostly head movement) or wear level (for heavily used SSDs). As indexing strategy (including PK generation) plays a role, difficult to say IMO, if not premature optimization. OTOH, if the code is long enough in use it should be bug free, so eliminating will reduce the amount of code worked upon only minimally.
>>>
>>>>SQL Server does not keep deleted records like VFP does. If you delete a row, it is removed by SQL Server. Recycling records is something that isn't done in SQL Server.
>>>>
>>>>
>>>>>I know; I was not using RECALL (in VFP). I am setting a certain field value to 'D' and then look for these records (with 'D') and set the value back to empty. So my recycling (in VFP) is not Delete/Recall. So I could, in theory, apply it to SQL Server. But I am trying to simplify my code; hence this question.
>>>>>Thank you.