>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
>
>
I should know better (given your debating skills and knowledge) than to respond. However, since it is "Foolish Friday" I can't seem to resist. After all, I wouldn't want to break my tradition of making an idiot out of myself on Fridays (You can't make an idiot out of yourself, George. God beat you to it (rimshot)).

Having at least a small bit of knowledge of language design and implementation, I'd be hard pressed to come up with a solution that generated the same results without sacrificing performance. And performance has been one this product's hallmarks ever since Fox entered the field (Oh, I hope Dave Johns has SET PUNS OFF).

Given this, I'd also point out that there have been plenty of times when I have broken the rules of what would be considered good design. I'm sure that almost everyone here can say the same. However, there have always been justifiable reasons for doing so. Under the circumstances (and here this is simply a matter of opinion) I'd say it's justified.

Does it contribute to the "just too complicated" impression? I think either of us would be hard to quantify either side of that question. Perhaps so, but if so, certainly not to the extent that some of the other syntax does (Is that SELECT as in workarea, or SELECT as in query? or SELECT() as in function).

I'd also hasten to point out that not only is _TALLY faster than using RECCOUNT(), but it works regardless of where the result set is directed. Something that can't be said for RECCOUNT().