I have two statements that seem the same that look for the same rows with the same null values. One returns the correct results and one returns 0 results.
With this table having some null values:
Why is it that this statement returns 3 results:
But this block returns 0 results:
I realize the variable is an intermediate step, but the variable is null on initializing and then it is explicitly set to null so I do not understand the difference.
I suspect that the ansinull option is set to ON on your connection when you ran your first statement, and your first statement, by itself without any other information, is treating the "AAItemID = null" as a TSQL comparison and therefore is using TSQL semantics. As such, the test for null will do what you appear to want - that is check for null values - and will return three rows.
In your second example, the existence of the "begin ... end" block is telling SQL Anywhere that you are using the Watcom SQL dialect and hence is using ANSI semantics. As such the predicate "AAItemID = @NoVal" or even "AAItemID = null" will never match any rows because nothing equals null in ANSI-land.
Please see the NULL value documentation for more information about the treatment of NULL in SQL Anywhere.
As Ron has pointed out, if you are wanting to find null values, the correct method is to use "AAItemID IS NULL".
I haven't tested your code, but the first place I'd look it to see what exactly is in the @noVal variable.
Null is not a value, it is the absence of a value. You are probably treading in very dangerous territory here of unpredictable results.
If it your intent to look for nulls, use IS NULL.
Since it is not a value, the concept of equating null to another value doesn't make sense.
One of the many things I'm grateful for in SQLA is that it allows me to divide by zero to return a null, rather than crashing and burning on a div by zero error. (It's an option,and not default behavior since when, maybe release 4.something?)
answered 03 Dec '10, 20:11
If you want to have a comparison that returns TRUE in both cases:
and you're using SA12, you can use the new (and ANSI-compliant) NOT DISTINCT FROM search condition.
is sematically the same as
However, the performance for NOT DISTINCT FROM should be better, as it is sargable.
answered 04 Dec '10, 10:57