Export particualr column of Stored Procedure to a Table

  • Hi

    I know that It's possible to export the entire result set of a Stored Procedure to file, table etc.. but I wanted to know if it's at all possible to export just a particular column of the the Stored Procedure, generated in the results when the Stored Procedure is executed to a particular table?

  • No. You'd have to export the whole result set and then remove the columns you don't want. If it's something you do regularly then it's worth considering writing a different stored procedure that returns only the desired column.

    John

  • Another option would be to add a parameter that tells the SP which columns to return. So for example:

    (

    -- SP parameters plus a new one

    ,@returncols TINYINT = 0 -- default is current behavior

    )

    AS

    BEGIN

    IF @returncols = 0

    SELECT * FROM WhateverTable

    ELSE

    SELECT JustOneColumn FROM WhateverTable

    END


    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

    I think the danger with that is you end up with something like a catch-all query and you risk having a less than optimal execution plan cached. That's why I suggested a separate stored procedure.

    John

  • John Mitchell-245523 (11/6/2013)


    Dwain

    I think the danger with that is you end up with something like a catch-all query and you risk having a less than optimal execution plan cached. That's why I suggested a separate stored procedure.

    John

    Possible. I'm really not sure.

    But you could also do it by running the query that returns the columns you need in dynamic SQL. Then both execution plans would probably be cached. At least according to Gail Shaw's SQL in the Wild article on catch all queries.


    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 5 posts - 1 through 4 (of 4 total)

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