2009-06-25 16 views
18

Escenario: necesidad de pasar n argumentos a un procedimiento almacenado. Uno de los argumentos es del tipo varchar(x). Ese argumento varchar necesita construirse a partir de un puñado de otras variables varchar. Este problema utiliza SQL Server 2005, pero este comportamiento se aplica a todas las versiones de SQL Server.T-SQL: no se puede pasar como argumento cadena concatenada a procedimiento almacenado

Configuración:

DECLARE @MyString varchar(500), @MyBar varchar(10), @MyFoo varchar(10) 

SELECT @MyBar= 'baz ' 
SELECT @MyFoo= 'bat ' 

-- try calling this stored procedure! 
EXEC DoSomeWork @MsgID, 'Hello ' + @MyBar + '" world! "' + @MyFoo + '".' 

Esto produce la excepción en SQL Server: Incorrect syntax near '+'. Normalmente, puede pensar que el tipo de datos sería incorrecto (es decir, las variables son de tipos diferentes, pero eso produciría un mensaje de error diferente).

Aquí hay una aplicación correcta que compila sin error:

SELECT @MyString= 'Hello ' + @MyBar + '" world! "' + @MyFoo + '".'; 

EXEC DoSomeWork @ID, @MyString 

Pregunta: qué es lo que T-SQL no puede manejar la concatenación de un varchar como un argumento? Conoce los tipos, ya que fueron declarados adecuadamente como varchar.

Respuesta

19

La instrucción EXECUTE simplemente tiene una gramática diferente a otras declaraciones como SELECT y SET. Por ejemplo, observe la sección de sintaxis en la parte superior de las siguientes dos páginas.

instrucción EXECUTE: http://msdn.microsoft.com/en-us/library/ms188332.aspx

sentencia SET: http://msdn.microsoft.com/en-us/library/ms189484.aspx

La sintaxis para EJECUTAR sólo acepta un valor

[[@parameter =] {value | @variable [OUTPUT] | [DEFAULT]]

Mientras que la sintaxis para SET acepta una expresión

{@local_variable = expression}

Un valor es básicamente una constante codificada, pero se va a evaluar una expresión. Es como tener el varchar 'SELECT 1 + 1'. Es solo un valor varchar en este momento. Sin embargo, se puede evaluar la cadena como esta:

EXEC('SELECT 1 + 1') 

supongo que todo lo que estoy señalando es que el comando EXEC no permite expresiones, por definición, que se encontró al parecer ya. No sé cuál fue la intención de los desarrolladores de T-SQL cuando lo hicieron de esa manera.Supongo que la gramática se saldría de control si se permitiera lanzar subconsultas dentro de subconsultas en la lista de parámetros de un procedimiento almacenado.

T-SQL Expresión: http://msdn.microsoft.com/en-us/library/ms190286.aspx

+2

El sitio web al que se hace referencia en este comentario ya no está activo. – Buggieboy

+0

Gracias. He actualizado los enlaces para usar MSDN. – SurroundedByFish

2

No se puede hacer algo como esto sea

exec SomeProc getdate() 

usted tiene que poner todo eso en un parámetro como el que está haciendo en la consulta inferior Puede ser que sea porque es no determinista (al menos para las funciones)

Cuestiones relacionadas