July 29, 2008 at 1:55 pm
Hi all,
I'm currently attempting to write a stored procedure that will return the top 4 number of "matching" products based on a increasingly lax set of criteria. My approach is to create a table variable (I also tried this exact approach with a temp table) that will contain the list of matching product numbers. My query looks something like this:
DECLARE @relatedProducts table ( mainID int IDENTITY(1,1), productID nvarchar(255) )
DECLARE @count as int
INSERT INTO @relatedProducts (productID)
SELECT TOP 4 product_id AS 'productID'
FROM tb_products p
WHERE @category = 'hardware'
AND @series = '1500'
AND @diameter = '5"'
AND @type = 'caster'
AND p.product_id NOT IN (SELECT distinct product_id FROM @relatedProducts)
AND p.product_id <> @pid
ORDER BY NEWID()
SET @count = (SELECT COUNT(*) FROM @relatedProducts)
IF(@count < 4)
BEGIN
INSERT INTO @relatedProducts (productID)
SELECT TOP 4 product_id AS 'productID'
FROM tb_products p
WHERE @category = 'hardware'
AND @series = '1500'
AND @type = 'caster'
AND p.product_id NOT IN (SELECT distinct product_id FROM @relatedProducts)
AND p.product_id <> @pid
ORDER BY NEWID()
END
-- and so on....
SELECT TOP 4 *
FROM @relatedProducts
I'm trying to use the line:
AND p.product_id NOT IN (SELECT distinct product_id FROM @relatedProducts)
to ensure that I don't add the same product twice, because each successive pass will contain the products returned in previous passes. However, when this line is included in the successive queries, they don't return anything, even when the table variable (or temp table) is completely empty
Any ideas on what is causing this behavior? Is there an easier and more efficient way to refactor this procedure?
- Dave
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 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply