>>>>>>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
>>>>>
>>>>>Have you ever tried to index table. 8500 records is absolutely nothing for VFP. I have 3 million tables which retrieve records in milliseconds.
>>>>
>>>>You say most of the fields queried on have indexes... _all_should have them. And make SURE you have an index on deleted, especially if the app operates with SET DELETED = ON. Finally, check the optimization of your queries with sys(3054, 1).
>>>>
>>>>Erik
>>>
>>>I don't think that 8500 records will even show visible difference in regard to deleted(). 22 sec indicates that there are serious problems with database and/or interface design.
>>
>>Joy, have you tried this app on a stand-alone machine? No network, etc? It might be easier to approach if you knew the problems were (or were not) related to data access over the network.
>>
>>Barbara
>
>It performs only slightly faster on a stand-alone. You were correct about the deleted() index. I just tried it and it doesn't work. I have gone over the code several times to get rid of things like doubling the search, or being sure that all my commands were optimized.
>
>Yikes, Barbara. I just found it. After I wrote that last paragraph, I decided to go through one more time (this would make 11 or 12 times). It was so simple. It was an UPPER() added to the expression method (the one that builds the expression based on which fields the user chooses to search on, etc.). Wow. I'm a tad embarassed. Thanks for everything.
>
>Would you delete the deleted() index or keep it in?
>
>JR
>
>PS--To everyone else. . . uhh. . . nevermind. . .

Hi Joy,
Don't think embarassed, think "Gee, I was brilliant to find this myself".

Yes, you should DEFINITELY keep the deleted() index if you have SET Deleted ON. Any other SQL will be slowed to a crawl without it.

Barbara