>>....
>>>In the help under "Indexes Based on Deleted Records"
>>
>>But read the Note for the Min/Max - makes me wonder if the optimization is only adding the deleted flag to index key as well, eliminating the round trip to the table for each record to check deleted() status if no separate deleted() binary index is available to prune the record #s.
>>So there definately were optimizations in that, but if all touched the Rushmore Engine is not totally clear to me (too lazy to create more test code...)
>
>Hi Thomas:
>
>I've just made some tests, thanks to Gregory update on this, and found that the optimization cases described in the help are rigorously true, and when using aggregated functions, the only optimization used for DELETED() or with SET DELETED ON is when making indexes that adds "...FOR DELETED()", but simple indexes on just "DELETED()" are not used :-(
>
>But this index is not used only in this cases, in all others it is used anyway, so seems that adding "FOR NOT DELETED()" in every index is the most optimized approach.
>
>Too many years believing that "FOR" indexes where BAD and not optimizable :-(

downloaded latest (2014) version form vfpx, false empty() not optimizable description is still in there.
Perhaps such testcode should live in this project ?
I have no idea if/how such info should be entered into the chm-file, perhaps only a disclaimer pointing to the test prg.