I have been following this thread and I have to agree with Eric here.

Just because you have been using fox since the foxbase days doesn't mean you have all the answers and can't learn anything new. I have never had the problems you have described because I would never attempt to do what you are doing the way you are doing it.

Don't blame VFP for your bad designs.


>Hey! I'm one of VisFox's biggest fans. But our app was about to be released and was working great, then we went in and added indexes to our tables on DELETED(), a simple change, right?
>
>But after that, the entire app was GPF'ing and crashing. And we take alot of pride in our coding practices around here! Since we've been using fox since foxbase days!
>
>After about a week of serious analysis, we found that when we created the indexes, rushmore was able to 'fully optimize' our SQL statments, and started returning the dreaded 'filtered result sets'.
>
>Then everytime we used any of the following statements, it crashed:
>
>SELECT * FROM MASTER WHERE TYPE = 'CLIENT' INTO CURSOR CLIENTLIST
>SELECT CLIENT_ID DISTINCT FROM CLIENTLIST INTO ARRAY ThisForm.ClientList
>* This crashes now with ERROR 1815 because visfox doesn't allow subsequent SQL selects on filtered result sets.
>
>SELECT * FROM MASTER WHERE TYPE = ?cTYPE INTO CURSOR CLIENTLIST
>* This GPF's sometimes and other times reports variable 'cType' doesn't exist
>
>And the solution is to add NOFILTER to every SQL select statment?? IMHO, that was a kludgy patch to the product instead of fixing the engine so that the above errors do not happen regardless of the optimization level. And yes 'NOFILTER' is in the documentation, but there is no warning that the above errors can happen if you don't use it. There isn't even a knowledge base article on it.
>
>By the way, now that our app is both local and client/server, we use SQL passthrough and use the SAME SQL statments on both local and back end data.
>
>The nice thing about SQL server is we always know that we are getting the results we expect when we query the backend. We can even run the above statements regardless of SQLs optimization method and they always work. But switch the app to local tables, and we have to insert NOFILTER clauses into all of our SQL selects.
>
>Many of us with always be with VFP, but I've worked with a couple of companies now that have forced switching to VB with ADO (poor souls), because they believe that it takes too much work to create bug free apps in VFP.
>
>You and I don't think that way (of course), but they really need to make sure issues like this don't happen during development so more companies can pick up VFP and run with it and not have to devote so much time to troublshooting.
>
>
>
>>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' ;)
>>>