>>>>>I'd suggest putting an
>>>>>
OTHERWISE
>>>>> RETURN SPACE(12)
>>>>>
>>>>>in that CASE statement, just in case....
>>>>Ed R. Suggested that, too. It worked, which showed me that the SQL was IIIFing
>>>>records that didn't match my WHERE clause. Theoretically, there never should
>>>>have been an otherwise case.
>>>
>>>Yeah, I noticed that after I posted. :-( My experience has been that you should
always put the OTHERWISE clause in, because sooner or later, something will slip through....
>>
>>Normally, I'd agree. But in this case I had no otherwise to put. If it wasn't one of those three, then it shouldn't've been there. I didn't allow for VFP doing things screwy, I guess. :)
>
>VFP isn't really doing anything 'screwy'; you've made some assumptions about when certain aspects of the WHERE clause evaluation is taking place, and the odds are that, by quirk of fate, VFP is constructing a temporary index on the evaluated UDF before filtering the recordset. If you take a look at the documentation, you are warned that the order of evaluation of joins and projects is not necessarily determined by the order of the statements in the WHERE and JOIN clauses; VFP is given the flexibility to perform segments of the WHERE clause to attempt better optimization. If you must have WHERE clause sections evaluated in order, you'd better encapsulate things explicitly with parentheses to force evaluation in specific order.
Ok, I've learned my lesson. :)
Thanks,
-Michelle
