December 7, 2010 at 9:58 pm
Good question! But missed the Batch Separator(GO(default) or 😉 between the Insert statements.
INSERT INTO dbo.Employees(EmployeeID) values (1)
GO
INSERT INTO dbo.Employees(EmployeeID) values (2)
GO
INSERT INTO dbo.Employees(EmployeeID) values (3)
GO
INSERT INTO dbo.Employees(EmployeeID) values (4)
GO
Regards,
Jagan.
December 7, 2010 at 11:31 pm
jaganmohan.rao (12/7/2010)
Good question! But missed the Batch Separator(GO(default) or 😉 between the Insert statements.INSERT INTO dbo.Employees(EmployeeID) values (1)
GO
INSERT INTO dbo.Employees(EmployeeID) values (2)
GO
INSERT INTO dbo.Employees(EmployeeID) values (3)
GO
INSERT INTO dbo.Employees(EmployeeID) values (4)
GO
Which really arnt needed. None of them are (atleast not if your using SSMS).
But i also liked the question. Since it wasnt that long ago i ran into this somewhere on this site (QOD/Post/Article... something). And refreshing that now makes it much more likely that i will actually remember it 🙂
/T
December 7, 2010 at 11:32 pm
Yes, question is instrustive (for me), but BOL says:
Caution:
Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results
So, results may be different! By the way, using Set ansi_nulls off, the result is three rows: "2, 3, 4"
December 8, 2010 at 12:07 am
savosin_sergey (12/7/2010)
Yes, question is instrustive (for me), but BOL says:Caution:
Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results
So, results may be different! By the way, using Set ansi_nulls off, the result is three rows: "2, 3, 4"
ANSI_NULLS settings are discussed every time null values are mentioned. If someone wants to make it a point of the question, they can add the "It depands" answer.
Null values in negative comparisons are allways dangerous.
December 8, 2010 at 1:20 am
Good question.
But this is not an explanation at all:
Explanation: If a subquery returns any null value the main query will not return any rows
I suggest the following explanation.
The SELECT query can be modified as follows:
select *
from dbo.Employees
where EmployeeID not in (SELECT NullableColumn FROM NullOperation)
-->
select *
from dbo.Employees
where EmployeeID not in (NULL, 0, 1)
-->
select *
from dbo.Employees
where (EmployeeID <> NULL) and (EmployeeID <> 0) and (EmployeeID <> 1)
The result of the comparison "EmployeeID <> NULL" is undefined for all values of EmployeeID (unless you set the ANSI_NULLS option to OFF). So the result of the WHERE clause is undefined (i.e. not true), and no rows are returned.
December 8, 2010 at 1:26 am
Interesting question. But at the least I will have to question the explanation ("If a subquery returns any null value the main query will not return any rows"). If you change the query to:
select * from dbo.Employees
where EmployeeID in (SELECT NullableColumn FROM NullOperation)
Then a single row is returned (1), even though the subquery still returns a null value. So I think a better explanation is that the IN operator returns NULL if the value is not found in the list, and the list contains NULL values.
December 8, 2010 at 2:08 am
Good question. But the explanation is not an explanation at all. I wrote a series of blog posts about NULLs, and one part covers (a.o.) this issue - you can find it at http://sqlblog.com/blogs/hugo_kornelis/archive/2007/09/22/dr-unknown-or-how-i-learned-to-stop-worrying-and-love-the-null.aspx. (I recommend reading the other three parts as well - links to parts 1 and 2 are in the opening paragraph, and a link to part 4 is in the comments).
savosin_sergey (12/7/2010)
Yes, question is instrustive (for me), but BOL says:Caution:
Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results
So, results may be different! By the way, using Set ansi_nulls off, the result is three rows: "2, 3, 4"
Results are unexpected, not undefined or unpredictable. Unexpected means that the results may not match human expectation, not that results may vary.
ANSI_NULLS is on by default, and ANSI_NULLS OFF is deprecated, so I think it's fair to assume ANSI_NULLS on unless explicitly told otherwise - except, maybe, when the author includes "it depends" in the answer options.
December 8, 2010 at 2:32 am
I like the point the question tries to make (which is a very important one), but the explanation is lacking. Some links would have been nice and an explanation of ANSI_NULLS would have been great too (even if it is set to ON by default and the OFF is deprecated. Some people are still working with earlier versions of SQL Server.)
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
December 8, 2010 at 3:22 am
mistakenly clicked on the NULLS answer... 🙁
nice question, thanks.
December 8, 2010 at 4:41 am
da-zero (12/8/2010)
Some people are still working with earlier versions of SQL Server.
But hopefully none of them are still using ANSI_NULLS OFF or any other deprecated features?
December 8, 2010 at 5:08 am
Toreador (12/8/2010)
da-zero (12/8/2010)
Some people are still working with earlier versions of SQL Server.But hopefully none of them are still using ANSI_NULLS OFF or any other deprecated features?
Some old applications are using ANSI_NULLS OFF.
Try to explain to users that filters of the type name not like 'honza%' don't return those lines where name is empty. They don't start with honza...
December 8, 2010 at 5:49 am
Caution:
Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results
This is not in the local BOL of my work environment. And I have no control over that.
I used to try to answer QOTD based on my knowledge and research in BOL.
But questions like this are the reason I now run the code first and that takes the fun out of it.
December 8, 2010 at 5:58 am
Nice question!
December 8, 2010 at 6:05 am
steven.malone (12/8/2010)
Caution:
Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results
This is not in the local BOL of my work environment. And I have no control over that.
I used to try to answer QOTD based on my knowledge and research in BOL.
But questions like this are the reason I now run the code first and that takes the fun out of it.
This logic i dont get at all. The question is great for showing a "gotcha" in SQL. If it isnt in your BOL... then even better. You just learned something that you dont know and couldnt have found out any other way (since its not in your BOL). The QOTD isnt there for us to score points... its there to teach/spread knowledge. Sometimes its not so good... but then the discussion is normally better. So either way... goal accieved. The points are just a bonus... if you get it right.
Seriously whats the point of running the code... getting your point and then moving along?
/T
Viewing 15 posts - 1 through 15 (of 48 total)
You must be logged in to reply to this topic. Login to reply