Please keep in mind that when using a DELETED() tag with VFP on a network that
there can be considerable delay when BROWSING large (500K+) tables - at least
that is what I have seen. It is true to VFP's SYS(5054,11) will not show full optimization
unless a deleted tag exists, but there are clear trade offs. We have gone so far as to
remove the deleted tags and left SET DELETED ON. The problem with large
network tables is that VFP wants to copy the deleted tags bitmap down to the local
drive.

>Juan (sorry Craig),
>
>You can get around the Rushmore "problem" by having an additional NON-filtered index on the original key. And, of course, you should have a separate index on DELETED(). For clarity this means, for the case described, that you 'should' have 3 different indexes defined:
>1) your filtered index;
>2) the field index (unfiltered, and a regular index);
>3) an index on DELETED().
>
>That way Rushmore will always be able to find what it "needs" (relative to the field) while you will have what you want.
>
>Good luck,
>
>Jim N
>
>>>I wanted the primary index to ignore deleted records using SET DELETE ON,but when i delete one and add another with the same primary key,
>>>the "Duplicate primary key error" appears.
>>>
>>>I solved this problem creating a filtered index (FOR NOT DELETE()),
>>>but Rushmore Technology won't use filtered indexes, so i think
>>>the application will lose performance when tables have many records.
>>>Am i right?
>>>
>>>Is there any other solution?
>>>
>>>I can't execute a PACK statement from the application because the
>>>multiuser environment won't have exclusive access on the table.
>>>
>>>
>>>Thanks
>>>
>>>Juan Carlos
>>
>>I get around this by not reusing primary key values.