Jim,

Thanks a lot for this clarification and for the interesting analogous (:) too.
OTOH, !this.value vs this.value=.f. should not be any difference, right?
And I vaguely remember that it MAKE difference in SQL statement, where second statement gives us a speed benefit. At least, it was in previous versions of FP, I believe.

Another observation, which I found in Help file: EMPTY() is not an optimizable function. So, instead of EMPTY() now I use ''<> myfield.

Am I right?

>
>There is no contradiction;
>
>lcVar = "123"
>
>lcVar is now a character expression, it is a character data type holding a string. If I ask TYPE() to tell the me value of the expression in that string it is numeric. Because type evaluates this way;
>
>TYPE(lcVar)
>lcVar = "123"
>The type of 123 is N
>
>Using TYPE(lcVar) is exactly the same as saying TYPE("123") because lcVar IS "123"
>
>Now the following doesn't work;
>
>lcVar = "ABC"
>TYPE(lcVar)
>
>Because the expression lcVar evaluates to ABC and that is not an expression unless it is the name of a field or variable. So the answer is U undefined.
>
>Analogous to this is the situation when someone thinks they need to compare a logical variable with a logical constant to get a valid expression. You don't, a logical expression IS a logical value just as a character variable is a character expression.