Thanks for all the information. I was leaning towards the '= ' and you confirmed what i thought.

The first one was a faster by about two seconds.

Thanks that worked.

I am sorry I figured it out. I found out the issue it was the parameters were giving me back exactly what I told them too. Sorry to have wasted...

Yes to all that. Here is the script in it's entirety:

DECLARE@ConsultantIDnVarChar(50)

DECLARE@AchieveLevelStartint

DECLARE@AchieveLevelEndint

DEclare @Level10bit

Declare @Level20bit

Declare @Level30bit

Declare @Level40bit

Declare @Level50bit

Declare @Level60bit

Declare @Level70bit

Declare @Level80bit

DECLARE @LineFilterVarchar(100)

DECLARE@statusvarchar(100)

DECLARE@MTDGreaterThanDecimal

DECLARE@MTDLessThanDecimal

DECLARE @QTDGreaterThanDecimal

DECLARE @QTDLessThanDecimal

DECLARE @StateVarchar(20)

DECLARE...

Actually that last statement worked fine but in order to get it functional I need to add it into my WHERE Clause then I can just get rid of that...

The @Level paramters are passed into the proc by the user. they can display which levels they want the proc to return. Each @level is a bit field.

I tried the...

Ok let eliminate the dynamic SQL. How would I introduce the @Level into the WHERE clause?

OK those statements look the same to me. But I was thinking I should be able to filter them out in my temp table before I even get to the...

I guess the next question is how do I fix it. How would I tell it that I need to omit the 0=1 levels.

I know the logic is sound but the issue is that in the case of the following result String:

SELECT * FROM #DLFiltered WHERE Active = 1 AND DownlineLevel...

The problem now is the point of the 1=1 and 0=1 is that I do not want to display the level that have 0=1 but right now it is still...

That link was really helpful. Thanks.

Seems straight forward but how would I handle the parameters that the Recursive query uses?

The 1=0 works great. Thanks