July 29, 2008 at 2:33 pm
What is the following parts of your query supposed to be checking?
WHERE @category = 'hardware'
AND @series = '1500'
AND @diameter = '5"'
AND @type = 'caster'
@category is a variable, which I am assuming is set somewhere above the code you showed us. This part of each query is not checking anything in the table, and if you have done the following:
DECLARE @category char(8);
SET @category = 'hardware';
Then, that criteria will be true for every single row. I think what you really wanted was something like:
WHERE category = @category
AND series = @series
AND diameter = @diameter
AND type = @type
...
Change the columns to the actual column names in your query.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 29, 2008 at 2:51 pm
Beyond the oddities of the Where clause with variables in it, you might also think about changing the Where Not In on the table variable to a Left Outer Join. Those are more predictable and usually perform better.
One of the things with Where Not In, is that if you have a single null value in the sub-query, you won't get any rows at all, because of the way Null works.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 29, 2008 at 3:00 pm
Jeff -
Sorry, I accidentally cut out too much of my original query... in each of those cases, it was matching a value in another table
July 29, 2008 at 3:02 pm
From what's posted, I can't tell why it would eliminate them. I've used that exact construct to manage duplicates in functions before, and it does work. It has to be something else in the query, but I can't tell what from what's posted.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
July 29, 2008 at 3:11 pm
GSquared -
It's good (if not confusing) to know that this approach is solid. When you did it, did you use temporary table or table variables?
I'm going to go back and try to double check I haven't made any other mistakes, but the query works just fine when the NOT EXISTS is removed. I'll also try re-writing the NOT EXISTS as an outer join.
July 29, 2008 at 3:26 pm
Turns out it was a typo. I was attempting to query an non-existent field in the table variable, and apparently that sort of thing doesn't throw any errors! Thanks for pointing out that my approach was valid - you always look a little bit closer when you know it *should* work.
July 29, 2008 at 3:41 pm
Glad it worked. I've made that same mistake. Not an easy one to catch.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 7 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply