>>From help;
>>

>>Rushmore Optimization and Code Pages
>>
>>Visual FoxPro does not use existing character indexes for tables created with a non-current code page. Instead, Visual
>>FoxPro builds temporary indexes to ensure correct results. This can result in non-optimization of SQL or other commands. 
>>To prevent this, ensure that the current Visual FoxPro code page returned by CPCURRENT( ) Function matches the table's 
>>code page returned by CPDBF( ) Function. This requires either changing the current Visual FoxPro code page, or changing 
>>the table's code page. For information about specifying the current Visual FoxPro code page, see Understanding Code 
>>Pages in Visual FoxPro. For information about specifying the code page for a table, see How to: Specify the Code Page of 
>>a .dbf File. If you cannot change either the Visual FoxPro codepage or the table codepage to match, you can force 
>>optimization to work as it did in Visual FoxPro 8 and prior versions using the SET ENGINEBEHAVIOR Command with either 80 
>>or 70 as a parameter.
>>

>
>Fantastic, thank you! Didn't look at codepage and fix it yet, but SET ENGINE made it fly. Even a simple LOCATE statement would take forever on this table.

I'll bet that these are older tables and that they have the DOS codepage instead of Windows. I ran into this with a client last year.

Tamar