>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.

Thanks Jim. I do have a question though. I have identical SELECT statements running prior to this one and after this one, without a NOFILTER designator; the only difference being that they select from different tables and they run absolutely OK. That is, RECCOUNT('cCursor') and _TALLY return the same number of records. These tables are also indexed. If the case is that VFP decides to optimize one statement and ignore the others, the same behaviour happens when running the SQL from the command prompt. It would interest you to know that if the table is copied to another with a different name, this problem does not occur. The table's name is 'bookbase'. I know its not a VFP reserved word. A reply would be very helpful.

Sanjay