>>>Nick,
>>>
>>>>>at least look semi-sane and extensible? (INLIST() can only have up to 24 values, it is not optimizable, but it's infinitely better than the original)
>>>
>>>>Or:
>>>>
>>>>IIF(alltrim(t.transs) $ "~CS~DV~L~R~RC~RD~V~ST~OP~", 1, -1)
>>>>this one is not limited to 24 values.
>>>>
>>>>(You may use IIF("~" + alltrim(t.transs) + "~" $... so it does not mix up R and RC and RD codes). You would not need alltrim() if all codes could be 2 char in length (along with the code field).
>>>
>>>your solution is not optimizable, INLIST is (As opposed as Ed suggested), so INLIST would be prefferable.
>>>
>>
>>Or do it the way I came up with so it's readable, optimizable, extensible and not limited to 24 items.
>
>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.