I think that that is not appropriate in this case. Selecting records without an index on deleted() will usually result in a "partially optimized" query, which should be faster than no optimization at all, but also faster than a "fully optimized" query, i.e., one with the inefficient index on deleted().

>Correct...
>That's why some of the VFP Commands have a clause NOOPTIMIZE and a SET OPTIMIZE command.
>
>
>>It's strange though because I went on a course about 4 years ago when it was just Visual FoxPro 6. This course was Microsoft approved and the guy who taught us (who had a Visual FoxPro MCP) told us that we must always set up an index on Deleted to improve performance. Basically I have always followed this advice.
>
>>Basically, if the index exists, the query might become Rushmore Optimizable;whereas without it, it won't. Now, this can cause confusion to some people. For Rushmore Optimizable doesn't necessarily mean it is optimal! The idea is that Visual FoxPro uses any index that will match the search expression, without considering whether doing so will likely make the query slower or faster. So, the expression is "Rushmore Optimizable", everyone is happy, until you find out, in some cases, that things are slower than with a "non-optimized" expression.