2011-12-02 53 views
110

tengo este script:T-SQL - función con parámetros por defecto

CREATE FUNCTION dbo.CheckIfSFExists(@param1 INT, @param2 BIT = 1) 
RETURNS BIT 
AS 
BEGIN 
    IF EXISTS (bla bla bla) 
     RETURN 1; 
    RETURN 0; 
END 
GO 

quiero utilizarlo en un procedimiento de esta manera:

IF dbo.CheckIfSFExists(23) = 0 
    SET @retValue = 'bla bla bla'; 

Pero me sale el error:

An insufficient number of arguments were supplied for the procedure or function dbo.CheckIfSFExists.

¿Por qué no funciona?

Respuesta

166

hay que llamarlo como éste

SELECT dbo.CheckIfSFExists( 23, default) 

De Technet:

When a parameter of the function has a default value, the keyword DEFAULT must be specified when the function is called in order to retrieve the default value. This behavior is different from using parameters with default values in stored procedures in which omitting the parameter also implies the default value. An exception to this behavior is when invoking a scalar function by using the EXECUTE statement. When using EXECUTE, the DEFAULT keyword is not required.

+49

Al ver esto estoy frustrado. No me estoy aprovechando del concepto 'default' aquí ... Necesito ir y cambiar todos los lugares ahora. – Lijo

+5

@Lijo, aún tiene la ventaja de no duplicar el valor predeterminado concreto en cada llamada. –

14

Con las funciones definidas por el usuario, debe declarar todos los parámetros, incluso si tienen un valor predeterminado.

El siguiente sería ejecutar con éxito:

IF dbo.CheckIfSFExists(23, default) = 0 
    SET @retValue = 'bla bla bla; 
24

se le puede llamar tres formas - con los parámetros , con DEFAULT y vía EXECUTE

SET NOCOUNT ON; 

DECLARE 
@Table SYSNAME = 'YourTable', 
@Schema SYSNAME = 'dbo', 
@Rows INT; 

SELECT dbo.TableRowCount(@Table, @Schema) 

SELECT dbo.TableRowCount(@Table, DEFAULT) 

EXECUTE @Rows = dbo.TableRowCount @Table 

SELECT @Rows 
0

Una forma de evitar este problema es utilizar procedimientos almacenados con un parámetro de salida.

ejecutivo sp_mysprocname salida @returnvalue, @firstparam = 1, 2 = @ secondparam

valores que no pasa en su defecto a los valores por defecto establecidos en el procedimiento almacenado en sí. Y puede obtener los resultados de su variable de salida.

+0

En general, cambiar su función a un procedimiento almacenado no es una buena solución, porque no se puede llamar a un procedimiento almacenado desde una consulta, pero sí una función. – Blade

+0

Es cierto, sin embargo, no es necesario llamar a todos los bloques de código desde una consulta. Se ha demostrado que sql no tiene un buen método para manejar los valores predeterminados de las funciones (usar la palabra clave predeterminada es casi tanto trabajo como agregar un valor). No es una buena solución general, pero funciona muy bien en ciertos casos de uso. –

Cuestiones relacionadas