Passing Tables as Parameters

  • Dwain Camps

    SSC Guru

    Points: 86893

    Comments posted to this topic are about the item Passing Tables as Parameters


    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

  • Vinay Kumar

    SSCertifiable

    Points: 6098

    Very good question !!! 🙂

    Thanks
    Vinay Kumar
    -----------------------------------------------------------------
    Keep Learning - Keep Growing !!!

  • Ron McCullough

    SSC Guru

    Points: 63877

    Very, very good question + nice question ... made me aware of the subtle elements of using tables as parameters, and thanks

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • TomThomson

    SSC Guru

    Points: 104773

    Nice question.

    But does the fourth batch fail with an error or with two errors? Anyone, I find it surprising that the two error messages give the same line number, as the first refers to the nested select which begins on the second line of the statement while the second error applies to the call to dbo.Test which is part of the main query, and the main query can't begin on the second line of itself.

    The fifth batch will fail as well of course since a batch separator has to be the first thing other than comments and white space on its line, so if anyone runs it their db will remain cluttered up with the type and the sproc.

    Tom

  • Dwain Camps

    SSC Guru

    Points: 86893

    L' Eomot Inversé (3/24/2013)


    Nice question.

    But does the fourth batch fail with an error or with two errors? Anyone, I find it surprising that the two error messages give the same line number, as the first refers to the nested select which begins on the second line of the statement while the second error applies to the call to dbo.Test which is part of the main query, and the main query can't begin on the second line of itself.

    Technically Tom, you are right that the fourth batch fails with two errors. I thought it might be a little much to expect people to realize that it would throw 2 so I left the proposed answer as "an error."

    L' Eomot Inversé (3/24/2013)


    Nice question.

    The fifth batch will fail as well of course since a batch separator has to be the first thing other than comments and white space on its line, so if anyone runs it their db will remain cluttered up with the type and the sproc.

    Ah yes. It appears the lack of line breaks is some artifact of the question submission process. In my original script, the two drops and the batch separator were all on separate lines.


    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

  • Dwain Camps

    SSC Guru

    Points: 86893

    Danny, Ron and Tom - Thanks to all for giving it a go.

    The history of this was that I was playing around with passing subqueries to TVFs, hoping for a shortcut to passing a table into the function. In the past, I've done this with XML and I was hoping there might be a more efficient way than SELECT/INSERTing into a table variable first and then calling the function with the table variable. Alas, that was not to be.


    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

  • kapil_kk

    SSC-Insane

    Points: 21316

    This wil also give error :

    DROP FUNCTION dbo.Test DROP TYPE dbo.MyTable GO

    as GO is present at the same line where it should not be....

    Alas I got wrong :w00t:

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • Dwain Camps

    SSC Guru

    Points: 86893

    kapil_kk (3/24/2013)


    This wil also give error :

    DROP FUNCTION dbo.Test DROP TYPE dbo.MyTable GO

    as GO is present at the same line where it should not be....

    Alas I got wrong :w00t:

    I'll refer you back to my answer to Tom's post just a little ways back.

    Clearly that last line should appear as:

    DROP FUNCTION dbo.Test

    DROP TYPE dbo.MyTable

    GO

    I have requested Steve to fix it if he can. Hopefully it won't confuse too many others.


    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

  • kapil_kk

    SSC-Insane

    Points: 21316

    dwain.c (3/24/2013)


    kapil_kk (3/24/2013)


    This wil also give error :

    DROP FUNCTION dbo.Test DROP TYPE dbo.MyTable GO

    as GO is present at the same line where it should not be....

    Alas I got wrong :w00t:

    I'll refer you back to my answer to Tom's post just a little ways back.

    Clearly that last line should appear as:

    DROP FUNCTION dbo.Test

    DROP TYPE dbo.MyTable

    GO

    Thanks 🙂

    I have requested Steve to fix it if he can. Hopefully it won't confuse too many others.

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • Koen Verbeeck

    SSC Guru

    Points: 258985

    Nice question, thanks!

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • (Bob Brown)

    SSCrazy

    Points: 2705

    Nice question to start the week. Thanks.

  • Raghavendra Mudugal

    SSChampion

    Points: 10658

    Simply the best; thank you for posting.

    ww; Raghu
    --
    The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.

  • Dana Medley

    SSCertifiable

    Points: 6764

    Thanks for the great question!



    Everything is awesome!

  • mtassin

    SSC-Insane

    Points: 23099

    Good question, I lost count of GO statements... 🙁 knew where it would fail... but thought that was the 3rd batch, not the 4th.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • TomThomson

    SSC Guru

    Points: 104773

    dwain.c (3/24/2013)


    Danny, Ron and Tom - Thanks to all for giving it a go.

    The history of this was that I was playing around with passing subqueries to TVFs, hoping for a shortcut to passing a table into the function. In the past, I've done this with XML and I was hoping there might be a more efficient way than SELECT/INSERTing into a table variable first and then calling the function with the table variable. Alas, that was not to be.

    Yes, it's a pity that there isn't a table expression that we can use. Of course the two errors can be reduced to 1 by using (values(...),(...)...) (only because the parser can't dream up anything it could substitute for the values expression, so that there's no dreamt up thing to be of the wrong type for the function call) but 1 error still means it doesn't work.

    Tom

Viewing 15 posts - 1 through 15 (of 26 total)

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