>Hi George,
>>>>>When i execute the folowing SQL query, i get the error colomn "WTG"not found.
>>>>>
>>>>>SELECT detail.avr_ari,;
>>>>> iif(Detail.avr_wtg=.t.,'J','N') as WTG;
>>>>>FROM general!detail;
>>>>>WHERE WTG='J'
>>>>>
>>>>>Is this an impossible kind of query, to include an expressionalias in the WHERE Clause ?
>>>>>
>>>>>Any idea's how to solve this ?
>>>>>
>>>>
>>>>Bjorn,
>>>>
>>>>The WHERE clause of SELECT si applied to the source tables, there is no fild named WTG in the source fields. You can change it to;
>>>>
>>>>WHERE Detail.avr_wtg = "J"
>>>>
>>>
>>>This will cause a data-type mismatch. If he's testing against the result of the iif(), he's got to use the HAVING clause.
>>
>>Naw, you don't need a HAVING or a comparison operator, simply

SELECT detail.avr_ari, "J" AS WTG;
>>FROM general!detail;
>>WHERE Detail.avr_wtg

will do the trick. Using Detail.avr_wtg = .T. slows things down.
>
>I agree you don't HAVE to use HAVING to solve this problem. BUT, if you need to test against the result of the iif() (or any function for that matter) you need to use the HAVING clause. That was my intended point.
>
>BTW, Is it REALLY faster to skip the '= .T.'? I've never tested that. I tend to be explicit so that my SQL converter can parse more easily for SPT to SQL Server or (soon) Oracle.

My tests indicate that it is by about 2.5 times (roughly). Some of this may be attributable to something I found out back in FPW 2.6. I haven't tested to see if it still applies. Using variables rather than literals can (or at least used to) improve performance of a query. Since .T. is a literal, and you're removing it, this may also apply.

I also think statements like...WHERE table.logicalfield = .T. are redundant, and, therefore, unnecessary. So even if there was not a performance difference, I'd code it this way anyway.