Biorąc poniższej tabeli:Konkatenowanie INT i VARCHAR wewnątrz EXEC nie produkuje błąd konwersji
USE tempdb;
CREATE TABLE #T(Val INT);
INSERT INTO #T VALUES (1), (2), (3), (4), (5);
Chciałem wykonać dynamiczne zapytanie SQL za pomocą EXEC
otrzymał Val
wartość:
DECLARE @sql NVARCHAR(MAX);
DECLARE @Val INT = 3;
EXEC ('SELECT * FROM #T WHERE Val = ' + @Val);
to wykonuje bez błąd i daje prawidłowy wynik.
Moim założeniem jest to, że będzie produkować błąd:
Conversion failed when converting the varchar value 'SELECT * FROM #T WHERE Val = ' to data type int.
Od @Val
jest INT
typu danych oraz zasad data type precedence kwerenda wewnątrz EXEC
muszą być zamienione na INT
.
Moje pytanie brzmi: dlaczego połączenie z numerem EXEC
nie spowodowało błędu konwersji?
Uwagi:
- Wiem o sp_executesql
. Nie pytam też o alternatywę. Po prostu pytam o wyjaśnienie, dlaczego nie powstał błąd.
- Odpowiedź na to question nie wydaje się wyjaśnić moją sytuację jako kwestia odnosi się do VARCHAR
VARCHAR
konkatenacji.
Ja * wierzę *, że jest to trzymanie w złych czasach. Nawet z powrotem na przykład SQL Server 2000, można "EXEC" z wieloma ciągami znaków '+ 'ed, które przekroczyłyby granice znaków 8000/4000 dla varchar/nvarchar w tym czasie. Dlatego uważam, że '+' wewnątrz 'EXEC()' jest * nie * standardowym operatorem konkatenacji ciągów. Mimo że funkcja jest określona tylko do akceptowania typów danych łańcuchowych, domyślam się, że oznacza to, że będzie sznurować wszelkie typy nie-łańcuchowe, a pierwszeństwo danych może zejść z krótkiego pomostu. Ale to tylko spekulacja, a więc nie odpowiedź. –
Podobne pytanie zostało zadane wcześniej: http://stackoverflow.com/questions/26135174/type-conversion-in-exec-statement – Alex
@Damien_The_Unbeliever, masz bardzo interesującą teorię, jedna obserwacja: poniższe nie działa : EXEC ("SELECT" + 3), ale konkatenacja z użyciem zmiennej 'INT' działa. – Alex