>>>>>>For primary key, don't you just set the index filter to !DELETED() if you might duplicate a deleted key?
>>>>>>
>>>>>>-Michelle
>>>>>
>>>>>Well, there are several ways to generate a unique ID. If her method that generates the key never reuses the same key, she could just blank all the fields in a record, except the key field. Deleting the record after this modified blanking would preclude the need for packing the table.
>>>>
>>>>But if she never reuses the same key, I don't see the point in blanking the record?
>>>>
>>>>-Michelle
>>>
>>>That goes for "never undelete". Even if it gets accidentally undeleted, it's blank and won't hurt no totals. OTOH, if at any later stage of development they decide to start recycling deleted records, blanked records are obvious candidates for recycling.
>>
>>Yeah, that's true. I guess the thought of such a permanent deletion scares me. My users often want to get back what they delete, even if it asks them if they're sure they want to delete.
>>
>>-Michelle
>
>That's what archives are for -- where I have been asked not to eradicate deleted records, but make them invisible during normal running I write them out to an archive (coffin.dbf) and add a limited access resurrection routine which will bring them back to life. :-)
>
>At one place where I did this I had an EOD routine that copied the file into 2 temporary files (dead.dbf and alive.dbf) then copied the live records back into the main database and reindexed it. This piece of work was running under dBASE III+ back in the dim and distant past. It wasn't pretty, but it worked and the indexes didn't get corrupted.
>
>Jen

That's a good idea. For my app, keeping delete records as they are works fine, but it's nice to know other methods for the future.

Thanks,

-Michelle