C'mon Erik, you call that "clearly documented???

I bet you always know what is happening because of places like this, because you sure couldn't figure that out from the documentation! And now that you know, of course you know (and are wary).

As for the documentation...

1) The clause is not even mentioned in the syntax 'diagram';
2) Where NOFILTER is mentioned it simply states "Include NOFILTER to create a cursor that can be used in subsequent queries. In previous versions...". This doesn't exactly tell you the WHOLE story now, does it????

While I'm here, I think that you are also mistaken about the VARTYPE() function, which you describe as performing exactly as documented. Looking that one up I find the last sentence to say that it returns "U" if you specify a variable that doesn't exist. Can you blame anyone for assuming that an object would also be considered a 'variable'. No where does the Help warn the user that it can/will give an error under specific conditions, while the statement cited certainly leads one to believe that "U" is the worst possible outcome to be expected.

Regards,

Jim N

>I always know what is happening, because I know Fox's behavior when returning a subset of a single table with no additional fields. If ever I need to depend on having a separate table, I use NOFILTER with the SQL statement, and I have never had a single problem or unexpected result.
>
>This behavior is clearly documented in the manual, so I don't think that it qualifies as sneaky or unstable.
>
>As far as compatibility with other backends and their inability to recognize "NOFILTER", when do you ever use the same SQL statement for local data as with remote? When views are concerned, this is all irrelevant because views don't exhibit the filtered data set behavior. If you are not using views, then you are using SPT and you won't use SPT on Fox data (unless you have a really messed up set of circumstances that require you ti use VFP's ODBC driver). So what's the problem?
>
>I didn't know that Fox had a reputation for being unstable. You might want to inform Brian Jones and his JFAST team of this, they have bet our country's national security on the stability of VFP data.
>
>If anyone can accuse VFP of being unstable, I am sure it is because of extreme multiuser issues or instances of corruption in certain environments, but I don't think documented, predictable behavior qualifies as an instability.
>
>>The key is 'as long as you know what is happening'. I don't think anyone disagrees that speeding performance is a bad thing, but when the engine *might* return different result types based on rushmore, it gives fox the reputation that it is not stable.
>>
>>When we all know it is stable, 'as long as you know what is happening' ;)
>>