>
>You want to have indexes set for the fields you are querying on but you also want to make sure that the queries are Rushmore optimizable. This is especially true in a network environment. A non-optimizable query will result in a lot of traffic because the worstation has to examine the physical records to resolve the query. A fully optimizable query just use the indexes to determine what records it needs to get from the server.
>
>It is very important that at least one side of the expression EXACTLY matches the index expression and don't use any negative logic (NOT is not optimizable). The SET FILTER command is optimizable but most people follow it with a GO TOP which is not optimizable and results in a sequential search through the file for the first record matching the filter. I saw a tip that said using LOCATE FOR without an expression worked faster than GO TOP. For the best performance I agree with Tony that SQL SELECT is probably the best bet. I use parameterized views in my applications to search for a subset of the data. Once the parameters are set, I just requery the view and present the results to the user.

Yes, LOCATE will set reset pointer to top of record fastest.

There is another option for the search. If the records that are required appear to be contiguous under an index, the best performance would be a SEEK(). Then populate a temp table with records in set using SKIP and display to grid.