If the problem often lands at your doorstep and the solution is not intended to be typable from every WS, put an instance of vfp or at least the runtime on the server and search directly there, cutting out network time penalties. Should shave off a few % of response time



>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!