>>>

IIF(INLIST(t.transs,'"CS"','"DV"','"L "', '"R "','"RC"', '"RD"','"V "','"ST"','"OP"'),1,-1)

>>>
>>>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.
>>
>
>That's true - but if you look at the strings he's checking, they're 4 byters encapsulated on either end with double quotes, at least the way I read it from the original "basket of mutltiple ORs". This is a much better, easier, and in VFP reality, probably faster from everything Christof has said about substring search performance.
>
>OTOH, I'd liek to see this nice little table MULT of:
>
>Code, imult
>"CS" 1
>"CT" -1
>"R " 1
>"RC" 1
>
>etc. etc. and dump the line by line IIF() ENTIRELY, turning into:
>
>SELECT t.*, mult.imult *(t.number*t.price) as bruto ;
> FROM t trans, mult, ;
> WHERE t.transs = mult.code
>
>Ain't that a sweet way to handle it?

Yeah, as we know in VFP there are at least 3 ways to handle anything, and some are sweeter then others... :)