>Sure it works? I've tried it against our zipcode table with "NOVI"
>(should find NOVI BEOGRAD, NOVI SAD, HERCEG NOVI and should omit
>BANOVIÆI and the like). It omitted all the records where first word was
>NOVI.
>
No, you're right, I did that at home without code :~) It should be:

where myfield like 'FORD %';
or myfield like '% FORD %';
or myfield like '% FORD'

as you have below. But doesn't this cover all cases?

>What we both probably missed here, is the fact that % assumes there is
>something non-blank which may come instead of it, so it can't stand for
>the left or right edge of the character field. Our example should really
>look like this
>
>

>   where myfield like '%FORD ';
>    or myfield like '% FORD %';
>    or myfield like '% FORD';
>    or myfield like 'FORD %';
>    or myfield like ' FORD%'
>

>
>The newly added 3rd and 4th OR clauses cover for right and left edges of
>the field... which is far from elegant etc etc.
>
>Then I tried various other SQL combinations, and the clumsiest and most
>ridiculous worked best:
> where ' FORD ' $ ' '+myfield+' ' :)))
>I know it's worse than "not optimizable", but it gives you exactly what
>you need.
>
>>))) is my comment and is not part of the proper syntax.

Hey, that's pretty neat! I don't know that it's any worse than 3 or 5 comparisons that aren't optimizable, even if they are individually "faster"...perhaps I'll test it.