Tsql help on Passing values as parameters

  • Hi all,

    Below is the data in the temp table and I have to pass 4 parameters and 4 values to get the results as:

    The main criteria is Cat > 200, Horse < 40, Lion > 100 and Tiger > 150.

    DECLARE @Result1 NVARCHAR(100),

    @ResultValue1 NVARCHAR(100),

    @Result2 NVARCHAR(100),

    @ResultValue2 NVARCHAR(100),

    @Result3 NVARCHAR(100),

    @ResultValue3 NVARCHAR(100),

    @Result4 NVARCHAR(100),

    @ResultValue4 NVARCHAR(100)

    SET @Result1 = 'Cat'

    SET @ResultValue1 = 200--(Greater Than 200)

    SET @Result2 = 'Horse'

    SET @ResultValue2 = 40 --(Less Than 40)

    SET @Result3 = 'Lion'

    SET @ResultValue3 = 100 --(Greater Than 100)

    SET @Result4 = 'Tiger'

    SET @ResultValue4 = 150 --(Greater Than 150)

    IF object_id ('Tempdb..#tTable') IS NOT NULL

    DROP TABLE #tTable

    CREATE TABLE #tTable(ColName NVARCHAR(100), ColVal VARCHAR(100))

    INSERT INTO #tTable(ColName, ColVal) VALUES ('a', '100')

    ,('aa', 'Nothing')

    ,('b', '120')

    ,('bb', 'NoResult')

    ,('Cat', '190')

    ,('Cat', '400')

    ,('Cat', '200')

    ,('Cat', '210')

    ,('d', 'Nothing')

    ,('e', '100')

    ,('i', '80')

    ,('f', 'Nothing')

    ,('Horse', '60')

    ,('Horse', '20')

    ,('Horse', '40')

    ,('Horse', '30')

    ,('Lion', '100')

    ,('Lion', '120')

    ,('s', 'Nothing')

    ,('Tiger', '140')

    ,('Tiger', '150')

    ,('Tiger', '160')

    ,('Tiger', '180')

    ,('y', 'NoResult')

    SELECT * FROM #tTable

    DROP TABLE #tTable

    Thanks all!

  • The main criteria can be AND/OR i:e

    Cat > 200 AND/OR

    Horse < 40 AND/OR

    Lion > 100 AND/OR

    Tiger > 150

  • No need to pass 4 parameters. Below, I haven't created your SP but have given you everything you need to do so.

    DECLARE @XML1 XML, @XML2 XML

    IF object_id ('Tempdb..#pTable') IS NOT NULL

    DROP TABLE #pTable

    CREATE TABLE #pTable(ColName NVARCHAR(100), ColVal VARCHAR(100))

    INSERT INTO #pTable

    VALUES ('Cat', 200), ('Horse', 40), ('Lion', 100), ('Tiger', 150)

    IF object_id ('Tempdb..#tTable') IS NOT NULL

    DROP TABLE #tTable

    CREATE TABLE #tTable(ColName NVARCHAR(100), ColVal VARCHAR(100))

    INSERT INTO #tTable(ColName, ColVal) VALUES ('a', '100')

    ,('aa', 'Nothing')

    ,('b', '120')

    ,('bb', 'NoResult')

    ,('Cat', '190')

    ,('Cat', '400')

    ,('Cat', '200')

    ,('Cat', '210')

    ,('d', 'Nothing')

    ,('e', '100')

    ,('i', '80')

    ,('f', 'Nothing')

    ,('Horse', '60')

    ,('Horse', '20')

    ,('Horse', '40')

    ,('Horse', '30')

    ,('Lion', '100')

    ,('Lion', '120')

    ,('s', 'Nothing')

    ,('Tiger', '140')

    ,('Tiger', '150')

    ,('Tiger', '160')

    ,('Tiger', '180')

    ,('y', 'NoResult')

    SELECT * FROM #tTable

    SET @XML1 = (

    SELECT ColName, ColVal

    FROM #tTable

    FOR XML PATH('R'), ROOT('X') )

    SET @XML2 = (

    SELECT ColName, ColVal

    FROM #pTable

    FOR XML PATH('R'), ROOT('X') )

    -- Display the two variables to pass into your SP

    SELECT @XML1, @XML2

    -- Now create an SP, pass in the two above values

    -- and do something like this

    SELECT z1.ColName, z1.ColVal

    FROM (

    SELECT ColName=y.value('ColName[1]', 'NVARCHAR(100)')

    ,ColVal=y.value('ColVal[1]', 'VARCHAR(100)')

    FROM (SELECT @xml1 AS XML1) x CROSS APPLY XML1.nodes('X/R') t(y)) z1

    INNER JOIN (

    SELECT ColName=y.value('ColName[1]', 'NVARCHAR(100)')

    ,ColVal=y.value('ColVal[1]', 'VARCHAR(100)')

    FROM (SELECT @xml2 AS XML2) x CROSS APPLY XML2.nodes('X/R') t(y)) z2

    ON z1.ColName = z2.ColName and z1.ColVal > z2.ColVal

    DROP TABLE #tTable, #pTable


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • I need to pass the values in SSRS report for the parameters. And here you are hardcoding the required values into #pTable but need to pass them. Please help.

  • etirem (6/17/2012)


    I need to pass the values in SSRS report for the parameters. And here you are hardcoding the required values into #pTable but need to pass them. Please help.

    I don't see what I've done as hardcoding anything.

    Pass in @XML2, which contains the parameters as you have (temporarily) stored them in #pTable.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • The below values need to be passed as parameters from SSRS report and these values may change everytime the report is ran. So they cannot be put into a #pTable.

    ('Cat', 200), ('Horse', 40), ('Lion', 100), ('Tiger', 150)

  • etirem (6/17/2012)


    The below values need to be passed as parameters from SSRS report and these values may change everytime the report is ran. So they cannot be put into a #pTable.

    ('Cat', 200), ('Horse', 40), ('Lion', 100), ('Tiger', 150)

    I happened to use a VALUES set to INSERT into #pTable with. But there's nothing saying you can't INSERT them into #pTable using whatever local variables you have them stored in using INSERT/SELECT/UNION ALL SELECT.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • Like this:

    DECLARE @Result1 NVARCHAR(100),

    @ResultValue1 NVARCHAR(100),

    @Result2 NVARCHAR(100),

    @ResultValue2 NVARCHAR(100),

    @Result3 NVARCHAR(100),

    @ResultValue3 NVARCHAR(100),

    @Result4 NVARCHAR(100),

    @ResultValue4 NVARCHAR(100)

    SET @Result1 = 'Cat'

    SET @ResultValue1 = 200--(Greater Than 200)

    SET @Result2 = 'Horse'

    SET @ResultValue2 = 40 --(Less Than 40)

    SET @Result3 = 'Lion'

    SET @ResultValue3 = 100 --(Greater Than 100)

    SET @Result4 = 'Tiger'

    SET @ResultValue4 = 150 --(Greater Than 150)

    IF object_id ('Tempdb..#pTable') IS NOT NULL

    DROP TABLE #pTable

    CREATE TABLE #pTable(ColName NVARCHAR(100), ColVal VARCHAR(100))

    --INSERT INTO #pTable

    --VALUES ('Cat', 200), ('Horse', 40), ('Lion', 100), ('Tiger', 150)

    INSERT INTO #pTable

    SELECT @Result1, @ResultValue1

    UNION ALL SELECT @Result2, @ResultValue2

    UNION ALL SELECT @Result3, @ResultValue3

    UNION ALL SELECT @Result4, @ResultValue4


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • But can I get the results without using XML and pass them as variables as below.

    DECLARE @Result1 NVARCHAR(100),

    @ResultValue1 NVARCHAR(100),

    @Result2 NVARCHAR(100),

    @ResultValue2 NVARCHAR(100),

    @Result3 NVARCHAR(100),

    @ResultValue3 NVARCHAR(100),

    @Result4 NVARCHAR(100),

    @ResultValue4 NVARCHAR(100)

    SET @Result1 = 'Cat'

    SET @ResultValue1 = 200--(Greater Than 200)

    SET @Result2 = 'Horse'

    SET @ResultValue2 = 40 --(Less Than 40)

    SET @Result3 = 'Lion'

    SET @ResultValue3 = 100 --(Greater Than 100)

    SET @Result4 = 'Tiger'

    SET @ResultValue4 = 150 --(Greater Than 150)

  • etirem (6/17/2012)


    But can I get the results without using XML and pass them as variables as below.

    Presumably so but IMHO it is messier.

    Personally, I like to pass as few arguments as necessary to any SP.

    Perhaps someone with more experience using SSRS can help you further.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

  • I tried your logic but the result should be

    Your result is:

  • That's because I didn't notice that Horse is the exception where it should be < while the others are greater than.

    You can change the logic on the INNER JOIN to use a series of ANDs and ORs to fix that issue. Something like this:

    ON z1.ColName = z2.ColName and

    ((z1.ColName <> 'Horse' AND z1.ColVal > z2.ColVal) OR

    (z1.ColName = 'Horse' AND z1.ColVal < z2.ColVal))

    Suggest you play around a little to understand the SQL I've provided you.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply