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' ;)
>