T-SQL: невозможно передать каскадную строку в качестве аргумента хранимой процедуре

Question

Сценарий : Необходимо передать n аргументов хранимой процедуре. Один из аргументов имеет тип varchar(x). Этот аргумент varchar должен быть построен из нескольких других переменных varchar. Эта проблема использует SQL Server 2005, но это относится ко всем версиям SQL Server.

Настройка

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 + '".'

Это создает исключение в SQL Server: Incorrect syntax near '+'. Как правило, вы можете подумать, что тип данных будет неправильным (т.е. переменные имеют разные типы, но это приведет к другому сообщению об ошибке).

Вот правильная реализация, которая компилируется без ошибок:

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

EXEC DoSomeWork @ID, @MyString

Вопрос : Почему является то, что T-SQL не может обрабатывать конкатенацию varchar в качестве аргумента? Он знает типы, так как они были правильно объявлены как varchar.

Answer 1

Оператор EXECUTE просто имеет другую грамматику, чем другие операторы, такие как SELECT и SET. Например, соблюдайте раздел синтаксиса вверху следующих двух страниц.

Оператор EXECUTE: http://msdn.microsoft.com/en-us/library/ms188332.aspx

SET оператор: http://msdn.microsoft.com/en-us/library/ms189484.aspx

Синтаксис для EXECUTE принимает только значение

[[@ параметр =] { значение | @variable [ВЫХОД] | [DEFAULT]]

Принимая во внимание, что синтаксис для SET принимает выражение

{@ local_variable = выражение }

Значение - это просто жестко закодированная константа, но выражение будет оцениваться. Это все равно что иметь varchar «SELECT 1 + 1». Это просто ценность varchar прямо сейчас. Тем не менее, вы можете оценить строку следующим образом:

EXEC('SELECT 1 + 1')

Полагаю, все, на что я указываю, это то, что команда EXEC не допускает выражений по определению, которые вы, по-видимому, уже обнаружили. Я не знаю, каково было намерение разработчиков T-SQL, когда они сделали это таким образом. Я полагаю, что грамматика просто вышла бы из-под контроля, если бы вам разрешалось бросать подзапросы в подзапросах в списке параметров хранимой процедуры.

Выражение T-SQL: http://msdn.microsoft.com/en-us/library/ms190286.aspx

Answer 2

Это ограничение в выражении EXEC. См. Проклятие и благословения динамического SQL для получения дополнительной информации.

Answer 3

Вы тоже не можете сделать что-то подобное

exec SomeProc getdate()

вы должны поместить все эти вещи в парам, как вы делаете в нижнем запросе Это может быть потому, что он не является детерминированным (по крайней мере, для функций)