Te sugerimos que pruebes esta resolución en un ambiente controlado antes de pasarlo a producción, un saludo.
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;
Tendrías que incluir todos los parámetros posibles que podrías 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 podría ser mejor construir 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 para acomodar una cantidad variable de parámetros, entonces esencialmente estaría usando SQL generado dinámicamente, 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 suponiendo 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 anulables 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, digamos, 5-10 escenarios diferentes, en lugar de escribir procedimientos almacenados individuales según sea necesario, en lugar de intentar una gran solución que se adapte a todos. Acercarse. Puede ser un poco complicado de mantener.
Pero si debes…
¿Por qué no probar SQL dinámico, como lo sugiere @EJ Brennan (Perdóname, no he tocado SQL por un tiempo, por lo 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 viejo hábito que adquirí en alguna parte, usado para ayudar a depurar/leer procedimientos dinámicos cuando se ejecuta el generador de perfiles de SQL).
Acuérdate de que puedes aclarar .