>Because it doesn't work in all cases.
>It only works if VFP cannot optimise the query to a filtered view of the original table.
>Or if the query is a join of tables.
>Of if you use the NOFILTER clause to force a cursor instead.
>I managed to totally BREAK an application somone else wrote, because they used RECCOUNT() on the result set instead of using _TALLY.
>I addded an index to the table which made it a fully optimisable select statement.
>VFP then returned a filtered view of the table, with _TALLY=1 but RECCOUNT() over 50,000!

I don't know where did you get this, but maybe we're not speaking of the same thing. What i mean, is always run your query/queries ( into a cursor, a table, a cursor NOFILTER or READWRITE ), then check reccount() on the resulting set ( generally the one you're going to send to your report ). There's no way you can run this, and on a result set of 1 record you get another number in reccount() ( unless you're standing on another area ). If this ever happens to you, it should be filed as a BUG.
Jaime