>Hello folks,
>
>In all my years of working with VFP, having a first...rushmore is not working for every table. This is a new Win7 machine with VFP9 on it.
>
>For some queries on certain tables, it all works perfectly.
>
>The test queries are simple; sys(3054) reveals rushmore optimization of "none".
>

>select * from ediinvoicelnes where invnum = "1055947"
>select * from ediinvoices where invnum = "1055947"

>
>Of course there is an unfiltered index on invnum in each table, and SET OPTIMIZE is ON. The data is sitting out on the network (W2K Server, don't laugh...no SMB2). I compiled the test into an .exe and ran it from outside "Program Files" to make sure there was no funny business going on there, same result.
>
>These queries run fine (optimized) on the machine sitting next to it (WinXP, VFP8).
>
>Any ideas? About to copy these tables locally to see if the network is to blame, but that is a stretch.
>
>
>Thanks,

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.