Для Nvarchar (Max) я только получаю 4 000 символов в TSQL?
Я установил носатый-Lua.
Пошаговые инструкции находятся в http://xchamitha.blogspot.co.uk/2012/11/adding-gadgets-to-ubuntu-1210-desktop.html
2 ответа
Вы объявили это как nvarchar (max), который позволяет 2 ГБ данных, поэтому он будет хранить 2 ГБ.
Что происходит:
- Тип данных еще не nvarchar (max) до присвоения @ sql1
- До этого это набор строк, каждая меньше 4000 ( constants )
- Вы объединяете короткие константы с короткими переменными (short = <4000)
- Итак, у вас есть 4000 символов, помещенных в @ sql1
Итак, вы должны убедиться, что у вас есть nvarchar (max) на правая часть.
Одна идея. Вторая строка объединяет nvarchar (max) с константой = nvarchar (max)
SET @SQL1 = ''
SET @SQL1 = @SQL1 + 'SELECT DISTINCT Venue...
....
Это ничем не отличается от целочисленного деления, которое происходит на каждом языке.
declare @myvar float
set @myvar = 1/2 --gives zero because it's integer on the right
Приоритет оператора (определяет приоритет типов данных) всегда "присваивание" последним .. .
Обновление : Ответ gbn правильный, а я ошибался. Как указано в MSDN , nvarchar (max) поддерживает до 2 ^ 31–1 байтов данных, хранящихся как UCS-2 (2 байта на символ, плюс 2 для спецификации). Кажется, ваша проблема связана с конкатенацией строк, а не с ограничениями типа данных.
Тем не менее, если вы используете его для построения строки SQL, почему бы не использовать VARCHAR? У вас есть имена полей, которые не могут быть представлены собственным набором символов базы данных (обычно Latin-1)?
Наконец, вы можете упростить всю проблему, просто не используя динамический SQL в своей хранимой процедуре. Создайте несколько возвращающих табличное значение функций, которые берут ваши строки предложения и возвращают таблицы, а затем просто СОЕДИНИТЕ их в своей процедуре. В качестве бонуса это почти наверняка будет намного быстрее, поскольку, по крайней мере, база данных сможет кэшировать тело SP как подготовленный оператор.