Saltar al contenido

Parámetros de procedimientos almacenados de SQL Server

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 .

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *