I haven't done any testing. I always use INLIST() though.


>Today I made a quick test: I run the same SQL, using INLIST(town,'AVON,NEWT') and town IN ('AVON','NEWT'). INLIST() worked considerable faster! What is your experience here?
>
>Nadya
>
>
>
>>>>>Nadya, Edward's suggestion of a grid is even better for this purpose - you can save discrete values into a cursor, and rather than using the non-optimizable INLIST() function, you can use an optimzable IN with a subquery.
>>>>
>>>>As of (I think) VFP 5, INLIST() IS optimizable.
>>>
>>>That'd be neat if true, but very tough unless VFP went and refactored it not to used the INLIST function - you have to check each record against the function return. You'd also have to change VFP's refactoring if the INLIST() were used in combination with another function by something, or contained in another expression like an IIF()).
>>>
>>>IN with a list of values (eg: ZipCode IN ('06511','90210','66666')) or a subquery is definitely optimizable.
>>
>>I see where it might be difficult for VFP to pull off, unless, like you said, it internally just 'emulates' the function. I confirmed my statement though- its a valid optimizablwe relational operator.