Pavel Menshchikov wrote:

> KR> The expression 'a'<>'b' would evaluate to false and 'a'<>null would
> KR> evaluate to null. Anding them together should yield false. But that's
>
> AFAIK, 'a'=null evaluates to false, not to null.

Sorry, but you're wrong. 'a' = null evaluates to null. Always. In many
situations though, null has the same effect as false - for example in
when-predicates in case expressions.

> KR> not the expression I have - I have the negation of its its DeMorgan
> KR> equivalent:
> KR> 'a' = 'b' or 'a' = null
>
> My mistake: giving you the expression ('a'<>'b' and 'a'<>null) I ment
> that CASE would choose its else-part (i.e. the expression is evaluated
> to true and the expression is equal to not('a'='b' or 'a'=null)). If
> 'a'=null evaluates to false (and not to null or "unknown"), DeMorgan
> is OK.

Yes, but that's not the case. But you're right that the case will choose
it's else-part (because the when-predicate evaluates to null, which is
not true).

> KR> Also, just a note: in my SQL book they call null UNKNOWN in the context
> KR> of three-state logic, like in when-predicates.
>
> I suppose FB has two-state logic, not three-state. Probably it's the
> SQL standard deviation (if the SQL standard states the three-state
> logic - I'm not sure).

FB can't possibly have two-state logic. SQL build heavily on three-state
logic. It's just that in many places null has the same effect as false.
This can make things confusing. So far I've found that thinking of null
as "unknown" makes otherwise unexpected results sensible in SQL.

In case expressions, all you have to remember is that a predicate is
"chosen" *only* if it evaluates to true, while null has the same effect
as false.

Thanks for trying to help Pavel!
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64