I made a slight mistake in my first message, sorry, it's been a while since I looked at the code. I'll clarify for the non-believers. :)

The application is written to display a large table in a grid, and the user types in a string and then I use a LOCATE to find the first record with that string. My previous post that said it was an SQL statement was wrong. Sorry to mislead all of you.

I'll be more specific this time. I'm running Visual FoxPro v3.0b on a Windows NT Workstation over a 10 Mbit Ethernet LAN connected to a server running Windows NT Server. The Server is just a basic file server with a bunch of FoxPro free tables on it and a shared drive mapped to the end users. Each user opens the table they need and a default view order is set by SET ORDER TO [default field] to change the order records are displayed in the grid. The user can change the view order whenever they want. They also can type in a string which is used with a LOCATE statement on the open table. The code looks like this:

ThisForm.LockScreen = .T.
lcOrder = ORDER()
SET ORDER TO
LOCATE FOR &lcSrchField = &lcSrchStr
SET ORDER TO &lcOrder
ThisForm.LockScreen = .F.
IF FOUND()
[I'm sure you get the picture...]

The variable lcOrder gets built to do whatever search is needed, but it basically looks like "[numeric field] = 10" or "[string field] = 'abc'", nothing fancy. The fields in question are indexed fields.

If I take out the SET ORDER TO and just leave it in whatever order it was previously in it takes around half an hour to find (even if the order it's set to is the field I'm searching on!). Search time depends on what record number I'm searching for, I measured the network traffic and if I search for the last record it moves the entire size of the table over the network, the first record comes up in about 1 second--it's doing a sequential search.

I know that the time is spent on the LOCATE statement because I tried putting WAIT WINDOW's directly around it ("Starting Locate", "Locate complete", etc.)

With the SET ORDER TO (and the matching SET ORDER TO &lcOrder later to set it back) it takes less than 1/2 second.

From reading the documentation I got the sense that it doesn't matter what the state of the table is, as long as Rushmore has the correct fields in the index, whether they are currently being used or not, it will do an optimized search. That doesn't seem to be the case.

Sorry again for confusing this with an SQL statement, but Rushmore-wise I would think it should be similar anyway.