George,

I would agree that, because it is "by design" it is not a "bug". But it is lousy design, to have any command or function which *can* have an *AMBIGUOUS* result. Such things just shouldn't be delivered.

Reminds of the VFP3 ListBox that was not a "bug" because it was by design - that you couldn't have more than 59 items in a list and select beyond that number and expect the selected items to stick.

We don't necessarily *need* a fixed and guaranteed firing order for things, but it sure would be good and helpful design.

It is not doubt things like this which contributes to many people's' impression that VFP is 'just too complicated'.

Cheers,
Jim N


>>>So, RECCOUNT() returns the number of the records in the current area, which is the one of the result set. BUT, the result set may be only a filter on the real table, so, the RECCOUNT() may return in fact the number of records in the real table (similar to a table that has an active filter). If the result is a real cursor, RECCOUNT returns the same thing as _TALLY.
>>
>>I have NEVER seen or had this happen, and if it does I feel it is a bug.
>>
>>BOb
>
>I've seen it happen on a number of occasions. Is it a bug? No, because it's by design in order to improve the performance of the query. Otherwise, you might get unacceptable performance.