Ed,

>>I agree this is probably the best way, but I think it could have a performance penalty because now you have to deal with more than 1 table.
>>
>
>ROFL! Compared to an IIF() and an INLIST() per line (hey, might as well ridicule my own code for being dumb!)? I can make an index? Rushmore still does bitmap matching? I am gonna have a tiny list of values...I am going to laught for hours, because the .003 seconds that might get saved on execution, comes back the first time I have to maintain this piece of code by 100,000 fold. In fact, more like 1*10^(pick a large number), I'm never going to have to touch this code, even if the multipliers change...
>
>Think for a billionth of a second about this. Apply neurochemical energy to the problem. You've gotta be kidding!!!!!!! Solve it once and never touch it again sounds right to me.

As I said, I completely agree with you. But one of your arguments was performance. I don't think the differance in performance would be significant. Instead I said that the inlist could be actually be faster, depending on the situation.

If the list is larger than a few item (we can't determine this by the data that is provided in this case) and isn't indexed the INLIST variant *could* be faster. Furthermore, the lookuptable could be wider than just one or two fields so the table size could be significant larger than you've suggested.

This said, I can imagine (though this would be very exceptional) that from a performance point of view the INLIST *could* be better.

Walter,