see if this query makes more sense for you:Success is 10% Intelligence, 70% Determination, and 22% Stupidity.\_/ _/ _/\_/ _/\_/ _/ _/- 881

Vinnie,Thank you! This query actually makes perfect sense to me - it forms the backbone of the query I ended up coming up with.

It's fast - it takes about 0.1 seconds to run. Unfortunately, it returns duplicates. I greatly appreciate your assistance, but don't want you to spin your wheels when there are more important items for you to apply your brain-power to.

Unless someone knows some sneaky optimization technique, my query, as ugly as it is, works. While not blazingly fast, it isn't a complete slowpoke, either.

Question: Would there be any performance gain (or penalty) if I added a primary key to the QuestionID column on @TempTestQuestions? I don't expect that we will ever have more than 5,000-10,000 questions total. Would the overhead of the index cancel out the performance gains? What would happen if we did have a large data set, say hundreds of thousands or millions of rows? Would the key become cost effective then?

If you are simply looking to eliminate duplicate questions, you can do it a lot of ways. Here's one.

Select *
from
(
select row_number() over (partition by topicid order by (select 1)) as Rowid,*
from
(
select row_number() over (partition by questionid order by (select 1)) as questionrow,*
from
@working
) bb
where bb.questionrow = 1
) aa
where aa.rowid <= aa.questionsfortopic

Select *
from
(
select row_number() over (partition by topicid order by (select 1)) as Rowid,*
from
@working a
inner join
(select min(ab.workingid) as workingid,ab.questionid
from @working ab
group by ab.questionid
) cc
on a.workingid = cc.workingidid
) aa
where aa.rowid <= aa.questionsfortopic

or create a indexed second table for

select min(ab.workingid) as workingid,ab.questionid
from @working ab
group by ab.questionid

and join it the same way as illustrated in this post.Success is 10% Intelligence, 70% Determination, and 22% Stupidity.\_/ _/ _/\_/ _/\_/ _/ _/- 881