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.