T-SQL: Nie można przejść łączone ciąg jako argument do procedury przechowywanej

Question

Scenariusz: trzeba przekazać n argumentów do procedury przechowywanej. Jednym z argumentów jest typ varchar(x). Ten argument varchar musi być zbudowany z kilku innych zmiennych varchar. Ten problem używa programu SQL Server 2005, ale to zachowanie dotyczy wszystkich wersji programu SQL Server.

Konfiguracja:

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

Wytwarza wyjątek w SQL Server: Incorrect syntax near '+'. Zwykle można by pomyśleć, że typ danych byłby nieprawidłowy (tj. Zmienne są różnych typów, ale wygenerowałoby to inny komunikat o błędzie).

Oto prawidłowe wdrożenie że kompiluje bez błędów:

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

EXEC DoSomeWork @ID, @MyString 

pytań: Dlaczego jest to, że T-SQL nie może poradzić sobie z konkatenacji varchar jako argument? Zna typy, ponieważ zostały zadeklarowane właściwie jako varchar.

Answer 1

Instrukcja EXECUTE ma po prostu inną gramatykę niż inne instrukcje, takie jak SELECT i SET. Na przykład obserwuj sekcję składni u góry dwóch następnych stron.

EXECUTE stwierdzenie: http://msdn.microsoft.com/en-us/library/ms188332.aspx

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

Składnia EXECUTE tylko przyjmuje wartość

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

Podczas gdy składni SET akceptuje wyrażenia

{@local_variable = expression}

Wartość jest po prostu stałą zakodowaną, ale wyrażenie zostanie ocenione. To tak, jakby mieć varchar "SELECT 1 + 1". To jest teraz tylko wartość varchar. Można jednak ocenić ciąg tak:

EXEC('SELECT 1 + 1') 

Przypuszczam wszystko jestem wskazując, że komenda EXEC nie pozwala wyrażeń z definicji, którą najwyraźniej okazało się już. Nie wiem, jaki był zamiar twórców T-SQL, skoro zrobili to w ten sposób.Przypuszczam, że gramatyka po prostu wymknie się spod kontroli, jeśli pozwolisz na wrzucanie podzapytań w podzapytaniach na listę parametrów procedury składowanej.

T-SQL Expression: http://msdn.microsoft.com/en-us/library/ms190286.aspx

Answer 2

Nie można zrobić coś takiego albo

exec SomeProc getdate() 

trzeba umieścić wszystkie te rzeczy w param jak robisz w swoim dolnym zapytania Być może dlatego, że nie jest deterministyczny (przynajmniej dla funkcji)

Answer 3

Jest to ograniczenie w stosunku do oświadczenia EXEC. Aby uzyskać więcej informacji, zobacz The curse and blessings of dynamic SQL.