Sanjay,
Whe there is no index on the tabel the optimizer decides it is faster to actually create a cursor because Rushmore cannot optimize a filter. When you put the index back it uses the filter approach. THIS IS NOT AN ERROR. This is by design. The NOFILTER option of teh SELECT command prevetns VFP from using the filter approach. For example;
SELECT * FROM Customer WHERE State = "NY" INTO CURSOR Results
May use the Customer table agina in another work area and set a filter on it, however;
SELECT * FROM Customer WHERE State = "NY" NOFILTER INTO CURSOR Results
will not use the table again with a filter, it will create a cursor that is independant of the source table. The NOFILTER will invariably cause the SELECT command to take longer.