This has been a problem "forever". The best way I've found to deal with this is to write behavior classes for different back ends to handle the differences in SQL syntax (DELETED, NOFILTER, etc.). A big pain once, but after that you don't have to worry about it anymore...

>This is definitely a big design flaw. The product should not act differently based on the engine decisions. The problem now is we use SQL Server and/or local tables with the same code. When we passed NOFILTER to SQL Server, it says 'Eh?', so we have to have code that strips out NOFILTER if SQL tables, and ADDS it if is a local table with a parameterized query!
>
>But dedicated are we to our beloved fox just the same ;)
>***********************************************************
>
>
>>>If you have a large table, and perform a SQL Select, Rushmore might USE AGAIN the table with a filter in effect. The BIG problem with this (which I think is a bug), is that the entire file is still available as are the records of original files. Rushmore should always return the same type of cursor regardless of what it had to do. The bug is also in the GO command, which disregards the rushmore filtered file and actually GO's to the record in the parent file, not the query result!
>>>
>>>For example:
>>>
>>>SELECT * FROM TESTFILE WHERE KEYFIELD = 1 && Keyfield is indexed
>>>* Should return 1 record
>>>GO 1
>>>? KEYFIELD
>>>GO 2
>>>? KEYFIELD && prints record 2 keyfield
>>>GO 3
>>>? KEYFIELD && prints record 3 keyfield
>>>
>>>Same Code with NOFILTER:
>>>SELECT * FROM TESTFILE WHERE KEYFIELD = 1 NOFILTER
>>>GO 1
>>>? KEYFIELD
>>>GO 2 && EOF error
>>>GO 3 && EOF error
>>
>>This is by design, and only happens when you do this type of SELECT (ie. one table, with no calculated fields, etc.). There are ways to get around it. Look at the NOFILTER clause. You can also add a calculated field. Note that when you do a multi-table join, VFP does a USE AGAIN on the tables.