Jim,

As usual a clear answer. And thanks also to John and Edward.

Actually I had made a mistake in my original message but thankfully
you all understood what I was driving at.

The problem I had was that I could not find anywhere, whether in the
Help, Manuals, or 3rd party books, any explanation as to whether
the FILTER option in the Table Designer was really a FILTER or
whether it was something that got applied only, and only, when
a key was being added to the index, and at no other time.

You have now all explained that it works like a true FILTER and
just that is enough of an explanation for me to stear clear of it
unless, as Jim explained, I create another index that is optimizable.

Much Thanks once again.

Michel.
================= Your original message follows =================

>>Hi all,
>>
>>In the good old FoxPro for DOS days I was used to always
>>creating an index on DELETED() in order not to display
>>deleted records.
>>
>>I now want to use instead the FILTER field available in the Table
>>Designer to have in there the !DELETED() clause in order to
>>achieve the same thing. Does anyone know if there are
>>performance penalties associated with using filter clauses
>>in index definitions ?
>>
>>Thanks in advance.
>>Michel.
>
>Michel,
>
>Indexes with FOR clauses are NOT used by Rushmore in optimization. This means, if you create all your indexes with FORs then you will need to have another st of indexes without the FORs for optimization.
>
>To revent deleted records from being seen, SET DELETED ON. The index on DELETED() does nothing about seeing deleted records, it does optimize the SET DELETE ON though. For an index to be used buy Rushmore it cannot contain any FOR condition and it must not contain NOT in the index expression.
>
>So,
>
>

>1. Create an index on DELETED() (<STRONG>not NOT DELETED())</STRONG>to optimize deletion resolution.
>2. Do not use FOR conditions unless you have another index on the same
>   expression without the FOR condition.
>