Ir al contenido principal

Parámetros OUTPUT en procedimientos almacenados: recuperar su valor desde la llamada

Los procedimientos almacenados de SQL Server pueden devolver valores bien sea a través de su valor de retorno, bien sea mediante los denominados parámetros OUTPUT.

Ahora bien, para que un procedimiento almacenado nos devuelva el valor de un parámetro OUPUT deberemos tener en cuenta dos cosas: que sea declarado como OUTPUT en el propio procedimiento y que en la ejecución del mismo se especifique la palabra clave OUPUT junto al parámetro en el que queremos que se nos devuelva el valor.


1. La primera premisa es, obviamente, declarar el parámetro como OUPUT en la declaración del procedimiento almacenado. Por ejemplo, imaginemos que queremos crear un procedimiento almacenado que sume dos números y nos devuelva el resultado. Reservamos el valor de retorno del procedimiento almacenado para gestionar posibles errores (por ejemplo, parámetros incorrectos).
CREATE PROCEDURE Suma
@sumando1 int,
@sumando2 int,
@resultado int OUTPUT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
IF @sumando1 < 0 OR @sumando2 < 0
RETURN 1
    -- Insert statements for procedure here
SET @resultado = @sumando1 + @sumando2
RETURN 0
END
En este caso, queremos que nuestro procedimiento almacenado "Suma" sólo admita números enteros positivos o el cero, por lo que en caso de recibir algún valor negativo en alguno de los dos sumandos, se devolvería un 1, indicando así un error en la ejecución del procedimiento almacenado (Nota: la gestión de errores mediante el valor de retorno de los procedimientos almacenados es sencilla pero limitada. Para una gestión de errores más completa, existen mecanismos como RAISERROR o THROW en combinación con bloques TRY...CATCH)


2. La segunda, imprescindible también, es responsabilidad de la llamada al procedimiento almacenado. Para que la variable en la que queremos obtener el valor de retorno sea rellenada por el procedimiento almacenado debemos especificar la palabra clave OUTPUT junto al parámetro que hace las veces de parámetro de salida (en el orden correspondiente de la llamada, por supuesto). De lo contrario, nuestra variable no se rellenará con el valor devuelto por el procedimiento almacenado. Es decir, un código como el siguiente, producirá un resultado quizás inesperado de NULL:
DECLARE @resultado int
EXEC Suma 1, 2, @resultado
SELECT @resultado
Para obtener el valor esperado, en este caso un 3, debemos escribir lo siguiente:
DECLARE @resultado int
EXEC Suma 1, 2, @resultado OUTPUT
SELECT @resultado
Hay que observar que ambas ejecuciones son correctas, ninguna de ellas produce error. En ambas, la declaración del procedimiento almacenado es correcta. Sin embargo, solamente especificando que queremos obtener el valor del parámetro de salida mediante la palabra clave OUTPUT, la variable @resultado ha sido rellenada correctamente en el código cliente que llama al procedimiento almacenado.


Comentarios

  1. buen día, tengo el siguiente caso: una base de datos en el cual una de las tablas posee un campo de tipo imagen, para cargar la información se me suministra un Excel y los archivos de imagen en formato JPG el nombre del archivo es una cadena que indica a que registro corresponde cual imagen. Al momento he hecho la carga de la información dejando el campo vacío y he creado una consulta en la cual puedo recorrer todos los registros y actualizar las imágenes pero no he logrado recorrer este dato usando un campo de esta misma variable para cargar las imágenes en el registro correspondiente:
    DECLARE @cnt INT = 1001;
    DECLARE @tmp VARCHAR(15);
    WHILE @cnt < 1101
    BEGIN
    SET @tmp = (SELECT NOMBREIMG FROM DATOSIMG WHERE ID=@cnt);
    UPDATE DATOSIMG Set IMAGEN = (
    SELECT *
    FROM OPENROWSET (BULK 'C:\IMG001.jpg',SINGLE_CLOB) AS IMAGEN)
    //FROM OPENROWSET (BULK 'C:\',@TMP,'.jpg',SINGLE_CLOB) AS IMAGEN)
    WHERE ID=@cnt;
    SET @cnt = @cnt + 1;
    END;

    ResponderEliminar
    Respuestas
    1. En concreto lo que deseo hacer es una consulta en la cual pueda remplazar el nombre del archivo por una variable de tipo carácter que reasigno en cada registro con el dato relacionado con el nombre de la imagen actual que corresponde

      Eliminar
  2. tengo un procedimiento que me arroja la cantidad de registros de una tabla de mi base de datos, pero quiero pasarlo a un metodo en java y no puedo necesito ayuda please me pueden escribir a este correoalberto_7355@hotmail.com gracias

    ResponderEliminar
  3. Gracias, me ayudo en clase, muy claro...saludos

    ResponderEliminar
  4. Gracias, me ayudo en clase, muy claro...saludos

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Aprendiendo a usar LEFT OUTER JOIN

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Variantes del SELECT COUNT con DISTINCT

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

Script para obtener el tamaño de todas las tablas de la base de datos

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.