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

Results from test:

1) All the LIKE code missed the simple case where myfield = 'FORD' That's enough to disqualify it already...
2) The '$' search was slightly faster at pulling 500 recs out of 10,000,
about .21 to .23 for LIKE on average
Conclusion: The '$' method is faster and more accurate. It's actually kind of elegant in an odd sort of way... :~))