The problem also exists with parameterized queries. For example,

nKeyField = 1
SELECT * FROM TESTFILE WHERE KEYFIELD = ?nKeyField
* This works becuase nKeyField is scoped during this statment.

Now in another method:
GO TOP IN TESTFILE && GPF's visfox or crashes program because
&& nKeyField is out of scope

However, if you delete the index on KEYFIELD, rushmore cannot set a
filter on the table and the above commands work OK.

This is actually how I found this problem, because I went back through our tables and starting optimizing the indexes. The system started GPF'ing all over the place! And several hours later I found it was in the parameterized queries that were now based on filtered tables!




>>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
>
>It's not a bug... as you know... Go (to) is one of the commands that doesn't respect the filter.
>
>BOb