>>> Regarding the Count(ff) variants of your selects, all of them return 100001 for me (? AX).
>>> What did you mean with BAD/GOOD in your sample code, Fabio?
>
>> BAD/GOOD SYS(3054) OUTPUT
>
>Okay, as far as I interpret Sys(3054) output and think it is ment, "none" as optimization level is the right answer for 1. select, as with set deleted off there is even no virtual where clause that needs to be optimized. Again sys(3054) only is not verbose enough to tell it optimizes Count(ff), just diplays filter optimizations, there ar no filters, so there is no optimization.
>
>But it's bad to be misinformed, true.
>
>>> ...(you may replace "blah" by any other constant).
>>Try this
>>
>>INDEX ON .NULL. FOR DELETED() TAG TNULL
>
>Okay: For you I should'nt have said "any", you always find the exceptions. For keeping the index short, let's index on a single character, eg "A". Or is .T. or .F. shorter? AFAIK these take one byte too and you also can't profit from binary indexes, INDEX ON .T. FOR DELETED TAG() TTRUE BINRAY does not work, because of the FOR clause.

I've used "A" as the index expression in this article http://msvfp.advisorguide.com/doc/01391. I believe .T. is being converted somehow internally where a straight character is not. Remember how numerics were being converted? I don't have proof, just a suspicion.

I didn't filter it for deleted. It was used to put the table in descending order by record number.