2011-03-04 28 views
6

Tengo una tabla de base de datos con la que intento actualizar/INSERTAR con un procedimiento almacenado. Vamos a definir la tabla de este modo:Procedimiento almacenado NULL Parámetro

CREATE TABLE Foo 
(
    Id   INT    IDENTITY(1, 1), 
    Name   VARCHAR(256) NOT NULL, 
    ShortName VARCHAR(32), 
    Sort   INT 
); 

He escrito un procedimiento almacenado similar al siguiente:

CREATE PROCEDURE Put_Foo 
(
    @Id   INT    = NULL OUTPUT, 
    @Name   VARCHAR(256), 
    @ShortName VARCHAR(32)  = NULL, 
    @Sort   INT    = NULL 
) 
AS 
BEGIN 
    SET NOCOUNT ON; 

    SELECT 
     @Id = F.Id 
    FROM 
     Foo AS F 
    WHERE 
     F.Name = @Name; 

    IF (@Id IS NOT NULL) 
    BEGIN 
     UPDATE 
      Foo 
     SET 
      ShortName = @ShortName, 
      Sort   = @Sort 
     WHERE 
      Id = @Id; 
    END 
    ELSE 
    BEGIN 
     INSERT 
     INTO Foo 
     (
      Name, 
      ShortName, 
      Sort 
     ) 
     VALUES 
     (
      @Name, 
      @ShortName 
      @Sort 
     ); 

     SET @Id = SCOPE_IDENTITY(); 
    END 

    RETURN; 
END; 

he simplificado en gran medida las estructuras de datos que trato pero espero que esto sirva mi punto. Mi pregunta es sobre cómo se procesan los parámetros. ¿Hay alguna manera de determinar dentro del procedimiento si @Sort se pasó como NULL o se estableció NULL con la declaración predeterminada en la lista de parámetros?

EDIT:

El propósito de esto es que no quiero parámetros NULL para anular cualquier columna en la instrucción UPDATE a menos que explícitamente se pasan de esa manera.

+0

¿Por qué no haces que las columnas no tengan valores predeterminados? –

Respuesta

6

No, no puede detectar cómo @Sort pasó a ser NULL. Si su objetivo es capturar cuando se establece explícitamente frente a la configuración predeterminada, sugiero usar un valor predeterminado diferente (tal vez uno que normalmente no se usaría, como -1). Entonces puede suponer que si @Sort es NULL, se transfirió explícitamente, pero si es -1, sabrá que se configuró de manera predeterminada.

+0

Eso podría funcionar, pero quería poder generalizar a múltiples procedimientos y parámetros. El objetivo final es que no quiero que los valores NULL que no se pasen explícitamente de esa forma anulen las columnas si se alcanza la ACTUALIZACIÓN. – rpf3

+0

Si SQL admite procedimientos de sobrecarga, puede crear 2 versiones de sproc, 1 con el parámetro y el otro sin él. Por desgracia, no es posible. –

+0

Lo sé ... Estoy tratando de evitar la creación de múltiples procedimientos por tabla que sean específicos de la situación – rpf3

0

Saque el valor predeterminado y el código y luego llamar a la proc debe proporcionar un valor (ya sea real o un valor NULL)

+0

No obstante, no siempre quiero pasar el parámetro. Por ejemplo, si llamo a Put_Foo desde una página que intenta crear un Foo basado únicamente en el Nombre, anulará el Nombre corto y el Ordenar si ya existe un Foo del mismo nombre. – rpf3

+0

@rpf: ¿Por qué lo anularía si * creó * un Foo? Entiendo, crear = insertar, ¿no es así? –

2

creo que esto es lo que busca. Si uno de los parámetros es nulo, se actualizará con el valor en la base de datos. La otra opción es actualizar una columna a la vez.

UPDATE Foo   
SET    
     ShortName = ISNULL(@ShortName, ShortName) 
    , Sort = ISNULL(@Sort, Sort) 
WHERE Id = @Id; 
Cuestiones relacionadas