>>>>>>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
>>>
>>>Blanking the record would remove any data that might be pulled in a select. She doesn't want the information in that record, so blanking the record is kind of a belt and suspenders approach. If she has some code that turns set deleted off, she could get unexpected results. Also, some people let others have access to their tables from VB or other products and the data could be reported there because that app might not know how to handle the deletion marks, etc.
>>
>>
>>Ah, ok. I guess my thinking is too narrow. I'm used to only one app handling the data and I control the DELETED status. :)
>>
>>-Michelle
>
>I guess you just have to code for what's expected. If she isnt' in an environment where someone else can get to the data, no problem. I was just trying to give her the benefit of my experience. She may not need it, but it doesn't hurt to make her aware of what might be "possible."< G >

It's good to know. I'm not going to be doing this same app forever. (Unless I can't find any contracting work < grin >) So I may end up in a situation where this would be useful. For this app, though, it would be actually harmful. My users frequently need to have things recalled.

-Michelle