Solución:
SQL Server no le permite pasar parámetros a un procedimiento que no ha definido. Creo que lo más cerca que puede llegar a este tipo de diseño es usar parámetros opcionales como este:
CREATE PROCEDURE GetTaskEvents
@TaskName varchar(50),
@ID int = NULL
AS
BEGIN
-- SP Logic
END;
Necesitarías incluir todos los parámetros posibles que puedas usar en la definición. Entonces sería libre de llamar al procedimiento de cualquier manera:
EXEC GetTaskEvents @TaskName="TESTTASK", @ID = 2;
EXEC GetTaskEvents @TaskName="TESTTASK"; -- @ID gets NULL here
¿Por qué pasaría un parámetro a un procedimiento almacenado que no lo usa?
Me parece que sería mejor crear declaraciones SQL dinámicas y luego ejecutarlas. Lo que está tratando de hacer con el SP no funcionará, e incluso si pudiera cambiar lo que está haciendo de tal manera que se adapte a un número variable de parámetros, entonces esencialmente estaría utilizando SQL generado dinámicamente que está frustrando el propósito de tener / usar un SP en primer lugar. Los SP tienen un papel, pero no son la solución en todos los casos.
Estoy asumiendo un poco aquí, pero supongo que la lógica dentro del procedimiento se divide a través de la tarea. ¿Y no puede tener parámetros que aceptan valores NULL como sugirió @Yuck debido a la dinámica de los parámetros?
Así que siguiendo mi suposición
Si TaskName = “Path1”, entonces algo
Si TaskName = “Path2”, entonces algo más
Mi pensamiento inicial es, si tiene funciones separadas con lógica de negocios que necesita crear, y puede determinar que tiene, por ejemplo, 5-10 escenarios diferentes, en lugar de escribir procedimientos almacenados individuales según sea necesario, en lugar de probar una gran solución única que se adapte a todos. Acercarse. Podría ser un poco complicado de mantener.
Pero si debes …
¿Por qué no probar SQL dinámico, como lo sugirió @EJ Brennan (Perdóname, no he tocado SQL en un tiempo, así que mi sintaxis podría estar oxidada) Dicho esto, no sé si es el mejor enfoque, pero podría esto posiblemente satisfaga sus necesidades?
CREATE PROCEDURE GetTaskEvents
@TaskName varchar(50)
@Values varchar(200)
AS
BEGIN
DECLARE @SQL VARCHAR(MAX)
IF @TaskName="Something"
BEGIN
@SQL = 'INSERT INTO.....' + CHAR(13)
@SQL += @Values + CHAR(13)
END
IF @TaskName="Something Else"
BEGIN
@SQL = 'DELETE SOMETHING WHERE' + CHAR(13)
@SQL += @Values + CHAR(13)
END
PRINT(@SQL)
EXEC(@SQL)
END
(El CHAR (13) agrega una nueva línea … un habbit antiguo que recogí en algún lugar, utilizado para ayudar a depurar / leer procedimientos dinámicos cuando se ejecuta SQL Profiler.)