>SNIP
>>
>>Yes, I remember the manuals stating something to this effect. But what I suspect that might actually happen, is that VFP parses the condition against the indices, and checking for an exact match. If this happens, then an index on NOT DELETED() might exactly match the implicit condition on NOT DELETED().
>>
>>This is just a suspition, of course, and it might be totally off track.
>
>Well I'd guess that you're totally off track < s>. Why would it mention the TAG defined with a NOT if it didn't mean it?

I recognize that the following is probably not in agreement with the manuals. But what I was imagining is the optimization engine uses the equivalent of the "$" operator to see if an index expression appears in the expression to-be-optimized. Let's briefly assume this is so; however, I recognize that the VFP engine may very work in a quite different manner:

1) Let's assume the index expression says accepted, and the expression to be optimized says ... and not accepted. Condition fulfilled: the index expression is included. (The NOT can easily be applied later, simply inverting ones and zeroes in the Rushmore bitmap.)

2) Let's assume the index expression says not accepted and the expression to be optimized includes ... and accepted. The index expression is not included in the expression to be optimized, and can't be used.

3) Finally, if the index expression says not accepted, and the expression to be optimized includes ... and not accepted. Since there is an exact match, the index can be used (according to the assumed logic). However, even if this were so, an index created without the NOT will be used in more cases, than one that includes the NOT.