Well, I didn't say it was a perfect solution. :) She was asking about using DELETED() with the index, so I told her how it's done...

-Michelly

>Michelle, the real problem here is that all FILTERed indexes cannot be used for Rushmore optimization.
>
>>That's something completely different. It doesn't help the deleted duplicate pk problem. Setting the filter to !DEL on the primary key makes it so it ignores deleted records in its uniqueness test.
>>
>>-Michelle
>>
>>
>>>Nope, just
>>>
>>>INDEX ON DELETED() tag isdelete && or whatever tagname you want to call it
>>>
>>>This will index every record but put in order of .f., then .t. just as if you were indexing on a customer id... It will retain the same natural order as the original record set has, but all the non-deleted will be grouped together and all the deleted will be grouped together. So when you find a hit with
>>>
>>>SEEK( .t., lcAlias, 'ISDELETE' ) && again, ISDELETE is the tag used for SEEK()
>>>
>>>if would stop at the first HIT record that was marked for deletion, then you can always re-assign the old unique ID such as customer ID to the next valid one in case there may have been any remnant records in other tables associated with the old customer. This is not a filtered index