Absolutely! SQL and buffering - erk, so easy to get burnt!

>Another reason not to use SQL for this: If the buffer is dirty, SQL operates on the original data -- it ignores changes made in the current editing session. So if you've added a record and not yet called TABLEUPDATE(), your count will be off by one.
>zahid
>
>>COUNT or CALCULATE work fine.
>>
>>

SET FILTER TO whatever
>>COUNT TO x

>>
>>Be very careful though that if you do use SQL do something like...
>>

SELECT COUNT(*) ;
>>  FROM mytable
>>  WHERE whatever ;
>>  TO ARRAY a
>>x= a[1]

>>Because if you
>>

SELECT * ;
>>  FROM mytable ;
>>  WHERE whatever ;
>>  INTO CURSOR c
>>x= reccount('c')

>>You may *still* get a wrong answer if "whatever" is Rushmore optimisable. This is because VFP will filter the table to create the cursor, and so reccount() will return the original number of records in the table! You could use INTO CURSOR c NOFILTER to avoid this problem in later versions of VFP
>>
>>>I've been wondering this for a while: Is there an accurate way to determine how many records are in a filtered table? RecCount() doesnt' work, it's not affected by filters. _TALLY doesn't work, Filters aren't an SQL command. (or at least Set Filter To isn't).
>>>
>>>What am I missing? Surely you don't have to select it to a cursor to find out how many were returned?
>>>
>>>TIA!