>>I've got a client who has an EXE written by me in v. 3 VFP. They can't go to VFP 5 due to the hardware constraints of some of the users, but I've migrated to v. 5 and still have the same speed problem.
>>
>>The client file is slower than a dead dog. It takes sometimes 22 seconds to pull up a record. The file isn't that deep (~8500 records), but it's quite wide (186 fields). The speed problem happens even on their faster workstations (Pentium 166 with 32M ram).
>>
>>I have the client form which has 5 pages in a frame but which uses delayed instantiation, so only the form that is active gets refreshed. I have a Find/List button off of that which fires a form allows the user to build a search criteria himself. He can also save the criteria and pull it up later if he wants, and most of the searches are made on indexed fields. If he chooses EXECUTE from the Find/List form, it does a LOCATE FOR. If he chooses the BROWSE mode, it does a SET FILTER TO. I expect the SET FILTER TO to be slow. But the LOCATE FOR is also slow, sometimes as slow as 22 seconds to pull up a record.
>>
>>Any ideas?
>>
>>JR
>
>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.

Thanx, Steve. Pls see my reply to Tony. I do use a locate for, then a set filter to, which is the most optimized you can make that command.

JR