Home Forums SQL Server 2014 Development - SQL Server 2014 Is it possible to embed a parameter in the name of stored procedure that's called from within another sproc? RE: Is it possible to embed a parameter in the name of stored procedure that's called from within another sproc?

  • pharmkittie (1/29/2015)


    I have some code that I need to run every quarter. I have many that are similar to this one so I wanted to input two parameters rather than searching and replacing the values. I have another stored procedure that's executed from this one that I will also parameter-ize. The problem I'm having is in embedding a parameter in the name of the called procedure (exec statement at the end of the code). I tried it as I'm showing and it errored. I tried googling but I couldn't find anything related to this. Maybe I just don't have the right keywords. Is it possible? If so, what is the syntax? Thanks.

    CREATE PROCEDURE [dbo].[runDMQ3_2014LDLComplete]

    @QQ_YYYY char(7),

    @YYYYQQ char(8)

    AS

    begin

    SET NOCOUNT ON;

    select [provider group],provider, NPI, [01-Total Patients with DM], [02-Total DM Patients with LDL],

    round(cast([02-Total DM Patients with LDL] as float)/[01-Total Patients with DM]* 100,2) as PercentLDLComplete

    , round(cume_dist() over ( order by round(cast([02-Total DM Patients with LDL]as float)/[01-Total Patients with DM]* 100,2) )*100,2) as CDist

    ,YYYYQQ

    from dbo.DMMeasures

    where [01-Total Patients with DM] > 0

    and YYYYQQ = @YYYYQQ

    order by round(cast([02-Total DM Patients with LDL]as float)/[01-Total Patients with DM]* 100,2) desc , CDist desc

    end

    exec DM@QQ_YYYYMT1

    parameter value examples: @YYYYQQ = '2014Q3' and @QQ_YYYY = Q3_2014

    First of all, in the batch above you need to have a GO directive between END and EXEC.

    To pass in parameters, I prefer to do so by name:

    exec DM@QQ_YYYYMT1 @YYYYQQ = '2014Q3', @QQ_YYYY = Q3_2014

    You can also pass them positionally but I've never felt that was a particularly maintainable option.

    Not sure if this answers your question but let me know.


    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