Почему значения, хранящиеся в столбце NVARCHAR, иногда дополняются конечными пробелами?
приложение, над которым я работаю, хранит строки Unicode в NVARCHAR(50)
столбец в базе данных SQL Server 2005.
иногда база данных возвращает строку, заполненную пробелами до максимальной длины столбца (50). В других случаях прокладка не происходит.
Я думаю, что тип этого столбца был первоначально указан как NCHAR
, но когда мы поняли, что пробелы добавляются, мы изменили его на NVARCHAR(50)
. Может, это как-то связано с этим?
В любом случае, можно ли отключить эту функцию?
уточнение
Я только что понял, что то, что я написал выше, не дает понять, что даже недавно вставленные строки заполняются пробелами.
6 ответов
nchar прокладывает поле, NVARCHAR-нет. Но если данные из старого поля, то пробелы останутся до обрезки.
" устаревшие " пробелы, вызванные типом nchar, ранее сохраняются из-за УСТАНОВИТЬ ANSI_PADDING НА по умолчанию.
вам нужно обновить RTRIM, чтобы удалить конечные пробелы.
Если вы преобразовали их ранее из NCHAR
to NVARCHAR
, любые данные, которые были введены ранее, по-прежнему будут содержать конечные пробелы. Вы можете обновить их все на:
UPDATE tablename
SET column = RTRIM(column)
NCHAR
столбцы заполняются пробелами, потому что CHARACTER
является типом данных фиксированной ширины, как требуется SQL
стандартные:
если
VARYING
не указан в<character string type>
, тогда длина в символах символьной строки фиксирована и значение<length>
.
и
пусть
T
иV
бытьTARGET
иVALUE
указанных в приложении, в этотSubclause
...
если тип данных
T
строка символов фиксированной длины с длина в символахL
и длина в символахM
ofV
меньше, чемL
, то первыйM
символыT
используетсяV
и последнееL-M
символыT
используется<space>
s.
отметим, что ANSI_PADDING = ON
(по умолчанию) функции и выражения, отличные от конкатенации и сравнения, неявно усекают конечные пробелы на VARCHAR
аргументы:
SELECT LEN(a), LEN(b), LEN(a + b)
FROM (
VALUES
(CAST('a ' AS VARCHAR(100)), CAST('b' AS VARCHAR(100)))
) AS q(a, b)
-----------
1 1 3
Как вы получаете значения в таблицу? Я думаю, что возможно, что если у вас есть сохраненный proc, и вы явно задаете длину параметра, который обновляет этот столбец до 50( скажем, через SqlCommand), он в конечном итоге заполнит его на ADO.NET уже на стороне.