In addition:
If the difference between server executed search and user machine search is large, you should also experiment with different ways to adress server data: subst, UNC directly, net use and so on. Warning: physical machines and even different VM and even same VM type hosted on WS or server may show different preferences. Test each scenario, do NOT generalize.


>>$ works perfectly, but just takes longer than users want to wait - lol!
>
>My gut feel is that 60 seconds for a SELECT to process 200K rows is way too long, even over a modern network. Is there any way you can test where the executable and a copy of the data are on the same physical computer? That would give you a best-case baseline. If you find performance across the network is much slower:
>
>- check that it's slow for more than 1 workstation i.e. eliminate the possibility of something funky with 1 particular workstation
>
>- test with antivirus real-time scanning disabled on both the server hosting the data files and ALL workstations that simultaneously access those files
>
>- check for anything else that may adversely affect file system performance e.g. "real-time" backup systems, or VSS backup job running on the server while users are trying to work, or File History doing a backup/sync on the workstation (Windows 8x/10 only, File History not available on W7)
>
>- if the server is virtualized, check that it has been provisioned with adequate disk I/O. It's easy to add too many VMs to a host that only has mechanical hard drives, such that all the VMs end up being sluggish. SSDs help a lot in that scenario
>
>Update: as for DNS, that's just one example of quite a few network settings that have to be configured properly. If workstations are domain-joined then the primary DNS server (preferably, the ONLY configured DNS server) must be the domain controller, which in turn will forward requests to your ISP if it hasn't cached them itself. A common mistake is to set workstations' DNS servers to be the ISP's DNS servers