Svein Erling Tysvær wrote:

> Please consider using STARTING as well. As long as you hardcode 'xy%'
> it doesn't make any difference (well, off the top of my head I don't
> remember whether one of them is case sensitive and the other not), but
> once you start using parametres, then STARTING can use an index
> whereas LIKE cannot.

Thank you for reminding me of STARTING. In this case It doesn't matter
because the entire SQL statement is generated on the fly so everything
is hardcoded right into the statement. Parameters would just be a
roundabout way of doing it. But I think I keep forgetting about STARTING
when it *would* be useful, so... :-)

> If the criteria is somewhat fixed, you could also add another field or
> table and use that to group the records. Using
>
> JOIN KJELLGROUPS ON KJELLGROUPS.FIELD = CHILD.FIELD
> WHERE KJELLGROUPS.CurrentGroup = :Query1Value

I don't follow you here. The set of criteria is *not* fixed. Anything
but. What *is* fixed and very well defined is the value set of
CHILD.FIELD (it's the set of SNI2002 line-of-business codes). But it's
up to the user to select *any* set of codes to match on.

> sounds much more tempting to me than ORing 283 values - regardless of
> speed (speedwise, I think you could benefit from having one such
> indexed field (CurrentGroup, PK) in the main table, but doubt anything
> could be gained with a lookup table).

Sorry, don't follow you here either, but that's probably because I
didn't follow you before. :-)

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64