Good points, but for troubleshooting network performance I usually cut straight to the chase, to what should generally be the fastest and least complicated option: IP address UNC e.g.

\\192.168.xxx.yyy\SomeShare\SomeFolder

That method does not require or use DNS, unlike

\\SomeServerHostName\SomeShare\SomeFolder

which does require DNS to resolve SomeServerHostName (disregarding NetBIOS for now)

Mapping a drive letter to a share invokes the network redirector, which adds another layer of complication.

If the IP address UNC form doesn't show improvement over a mapped drive letter then it's time to look lower in the network stack - wire data rate/reliability (may require network sniffing), I/O performance monitoring on the server (and its host if virtualized) etc.

Interesting comment about SUBST - have you used that for network shares? I've found it handy for mapping drive letters to local folders. I maintain one legacy system that expects hard-coded F: and O: drives to be present. On my dev machines I can map those drive letters to folders with local copies of the production data, for test purposes.

>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