T-SQL logic (data is not in table and is in table)

Ok, I have some simple SQL code that is not working as expected.

I have 2 tables ([IVOS].[dbo].[claim] and ivos.dbo.iso_cs). I want to see if a claim_number is in the first table and not in the second.  Well, if I use the attached could, I get nothing returned.  This seems fine, but if I un-comment the NOT, then I get nothing returned.  But how can this be? The claim_number either is in the ivos.dbo.iso_cs or not in the ivos.dbo.iso_cs table, but the query returns nothing worth or not the NOT is used.
select claim_number
from 
[IVOS].[dbo].[claim]
where
claim_number = '2009102428'
and
claim_number   in (
select claim_number
from 
[IVOS].[dbo].[claim]
)
 
 
and
claim_number 
--NOT
  in (
select claim_number
from 
ivos.dbo.iso_cs
)

Open in new window

rmundkowskyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nkhelashviliCommented:
select claim_number
from
[IVOS].[dbo].[claim]
where
claim_number
 not
  in (
select claim_number
from
ivos.dbo.iso_cs
)
0
rmundkowskyAuthor Commented:
Your code does not work either, granted I had to change it to this for the test:

   select claim_number
   from
   [IVOS].[dbo].[claim] as c
   where
      c.claim_number = '2009102428'
      and
        c.claim_number not in (
              select claim_number
              from
              ivos.dbo.iso_cs
        )




BTW, the following does return a value:

select claim_number
      from [IVOS].[dbo].[claim] as c
      where
      c.claim_number = '2009102428'
      and
      c.claim_number   in (
            select claim_number
                  from [IVOS].[dbo].[claim]
            )
0
rmundkowskyAuthor Commented:
Oh, I just found out that the server is running in SQLServer 2000 mode. I assume this may cause the query to not work.
0
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

rmundkowskyAuthor Commented:
This does work though:

select claim_number
      from [IVOS].[dbo].[claim] as c
      where
      c.claim_number = '2009102428'
      and
      c.claim_number   in (
            select claim_number
                  from [IVOS].[dbo].[claim] as b
where c.claim_number = b.claim_number
            )
      and
      c.claim_number  not  in (
            select claim_number
            from ivos.dbo.iso_cs as a
where c.claim_number = a.claim_number
            )
0
folderolCommented:
This LEFT JOIN has the exact same results as using the IN construct, and performance should be better, although frequently not as good as if you used EXISTS, which I think you really were attempting, not IN.  The LEFT JOIN has the debug advantage (which is why I'm suggesting it) of returning evidence for or against a match without modification, since the column cs.claim_number will be null in the results if it doesn't exist, and then you can uncomment the last line.


select c.claim_number, cs.claim_number
from [IVOS].[dbo].[claim] as c
left outer join ivos.dbo.iso_cs as cs
on c.claim_number = cs.claim_number
where c.claim_number = '2009102428'
--and cs.claim_number is null
0
rmundkowskyAuthor Commented:
I agree that the way you have it coded is much more efficient.  But what I don't understand is why the code I presented does not return the correct result?

I mean, does SQL Server 2000 return incorrect answers if a query is too big or slow?
0
dportasCommented:
To take a generic example:

SELECT a
FROM t1
WHERE a NOT IN
 (SELECT b
  FROM t2);

If b contains a null then this query will always return zero rows, whether or not any a value exists in the b column. This is the correct result in standard SQL and in all versions of SQL Server. Therefore the NOT IN query is not equivalent to the apparently similar LEFT JOIN query or to a correlated query using NOT EXISTS. This is often overlooked by people who think EXISTS should work the same as IN. The fact that they are different is sometimes called the "EXISTS bug" because EXISTS always returns a TRUE or FALSE result whereas IN / NOT IN can be TRUE, FALSE or UNKNOWN.

The simplest answer is to modify your query with WHERE b IS NOT NULL:

SELECT a
FROM t1
WHERE a NOT IN
 (SELECT b
  FROM t2
  WHERE b IS NOT NULL);


0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JestersGrindCommented:
Can claim_number be NULL in iso_cs?  If so, that is probably the issue that you're having.

From BOL:

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.

It's better to use EXISTS like the example below.

Greg



SELECT claim_number
FROM [IVOS].[dbo].[claim] as c
WHERE c.claim_number = '2009102428' 
AND NOT EXISTS(SELECT * FROM ivos.dbo.iso_cs as a
                WHERE c.claim_number = a.claim_number)

Open in new window

0
rmundkowskyAuthor Commented:
Wow, that sounds like the answer. Thanks all, I think Dportas nailed it, though the other inputs are helpful from a practical standing.

I guess the theoretical idea is that if NULL is in the set then the set is really larger than the set. So NULL is more than another value in the set that happens to be labeled NULL, but instead is kind of saying you can match against everything outside the set, but you still don't end out with a TRUE or FALSE.
0
dportasCommented:
You are right that null doesn't behave like a regular value. Nulls aren't really values at all, they are a type of marker.

Unfortunately SQL isn't very consistent about how it uses nulls and its treatment of them is a long way from conventional logic, maths or even common sense. You just have to learn and remember the quirks of nulls. You can also try to avoid them as much as possible by making all your columns non-nullable but unfortunately they still crop up in some queries where you don't expect them.

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Query Syntax

From novice to tech pro — start learning today.