>Thanks, Mike. There isn't, then, any way of avoiding the $ I take it...

If what you truly need to do is find a substring that could be located anywhere in a field's value, then I don't know any other way.

OTOH sometimes people want to do substring searches to, say, "zero in" on values. For example, suppose someone is searching on surname and they type "mca", and you want to be able to get the list of surnames that start with that string. In that case you might want to use LEFT() rather than $, it will be faster - but by how much I don't know.

With a modern network, server computer and workstations, running a SELECT against quite a few rows should be fairly quick. How many rows are you querying, and how long is a "long time"? It might be worth checking some networking parameters e.g. speed should be gigabit wired (not wireless), networking should be properly configured (e.g. DNS). Antivirus should be set to exclude VFP data folders and workstation temp file folders - you could test with real-time scanning temporarily disabled on server and workstations.

If you're not doing it already you could try to SELECT only the columns you need (rather than *), if each row has a lot of columns and pudgy memo fields. That will reduce network traffic and should speed things up. Taking that to an extreme, in some cases you can make things more responsive if in your initial query you only retrieve the matching primary keys, then for each row the user wants to view you later run another query to get the rest of the columns you need for just that row.