>Yes, Al - the problem is that the string can be anywhere in the field. It is a name field.
>
>I have an incremental search that solves for 95% of the searches, but the GIGO (garbage in = garbage out) effect from users messes things up. As an example - there is a customer with the last name CONTEH - they were looking for a current job ticket for him frantically, but found nothing, were jumping all over me for the search not working, so I used 'CON' $ lastname, got a list and found the name, but a minimum wage user had spelled it 'CONETH', so I have to write in a last ditch type search where 'CON' $ lastname would be applicable - just it takes a minute to go thru a hundred odd thousand
>records, and with today's instant gratification attitude, that just isn't acceptable. So - the answer to the questions asked 1. Yes - the substring is anywhere in the field. 2. Reccount is a couple of hundred thousand. 3. A 'long time' is a minute.
>
>Yes - network is wired gigabit, and very responsive under normal use. Yes - DNS is used. No - * is not used in SQL Select when I use it - only the relevant fields.
>
>$ works perfectly, but just takes longer than users want to wait - lol!
>
>Thanks everybody for their input thus far - really appreciate it!

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