Dennis Mulder wrote:
<snip>

>If you're searching for a substring when using "like 'substring%'",
>you'll have to parse the customer name into separate words/strings and
>put these substrings together with the customer id in another table.
>This will then be your search table, with the substring column and the
>customer id field as an aggregate primary key.
>You can write a stored procedure that parses the customer name and
>append the substrings and customer id in your search table when you
>enter a new customer. Drop the doubles in your substrings. So "the
>catcher in the rye company" will be "the catcher in rye company".
>
>

<snip>

I think the substring idea is a great one.

It took me a little while to understand what you were having me do with
the substring search table. You're suggesting I take the customer name,
and break it up into it's searchable parts, and store each part (with a
duplicate id number) in the search table. This way a high-speed indexed
search can find a subgroup of id's - with the tradeoff of higher
insert/update times (not a concern for me for this) and increased disk
usage (also not a concern right now).

--
Daniel