One more suggestion/explanation.
22k records is not much, but if you have large size of a single records...
Well, imagine apps on 2 computers that try to scan the same table (perform a search). Second app started 1 second later, so first app already made a scan of, say, 2000 records. After second app start, to scan the table and read information, the Operation System at the server computer should work for both. So, when first app reads data, it switch the HDD heads to locate the record 2001. Forst than swicth to locate the record 1. Than 2002, than 2 than... As you see, HDD heads will jump around slowing down the process dramatically. This is, of course, only in case there are no buffering by the server OS.
So, the place you require to start from, is to examine the server machine OS resources to see if it is able to cache all 22K records of that table include index files. Probably OS cannot do that so HDD heads jump around to get required data sloing down the process.
If you canot manage to solve this OS/hardware problem, I would also suggest to alter the app logic so second app will wait until first app finish search.
Finally, such search is quite slow. Better do not use the Wizard, make your own search system or use some VFP frameworks. This way you can define indexes for search, search by index is MUCH more quick that will make the chanse of simultaneous search quite little.
Vlad Grynchyshyn
vgryn@softserve.lviv.ua
The professional level of programmer could be determined by level of stupidity of his/her bugs