Len() против длины данных() в SQL Server 2005

Недавно я столкнулся с проблемой при использовании len() в запросе для определения длины запроса, len() не учитывал конечные пробелы в значении. Но datalength() конечные пробелы.

Означает ли это, что если я делаю какую-то операцию, которая имеет дело с фактической длиной значения, тогда я должен использовать dalalength() len().

Пример: если мне нужно, чтобы значение определенного значения было длиной 10 символов. т.е. если значение составляет 3 символа, я должен добавить к нему 7 пробелов.

Ответ 1

Да, именно то, что вы должны делать. Если вы хотите просто получить количество символов, исключая пробелы, вы должны использовать функцию LEN(), а во всех остальных случаях DATALENGTH().

Даже документация LEN() содержит информацию о том, что для получения количества байтов для представления расширения вы должны использовать DATALENGTH()

Вот ссылки на документы MSDN:

LEN()

DATALENGTH()

Ответ 2

Будьте осторожны. DATALENGTH возвращает количество используемых байтов, а не количество символов.

Ответ 3

len подсчитывает количество используемых символов, а не необходимое хранилище, это будет еще более очевидным, если вы используете nvarchar вместо varchar

len не считает конечные пробелы либо

взгляните на это

declare @v nchar(5)
select @v ='ABC  '


select len(@v),datalength(@v)

а выход для len равен 3, а выход для datalength = 10

Ответ 4

Просто используйте Replace():

SELECT LEN(REPLACE(N'4 Trailing Spaces:    ', ' ', '_'))

Это заменит конечные пробелы символом, который LEN() будет фактически считать.

Проблема с DataLength() заключается в том, что вам нужно следить за тем, чтобы ваша строка была Unicode (nChar, nVarChar) или ASCII (Char, VarChar), чтобы узнать, нужно ли также разделять длину данных строки Unicode на 2.

Ответ 5

Я собирался использовать Len (Replace ('blah blah', '', '_') когда он ударил меня, он может быть более эффективным в использовании. Просто опубликуйте, если кто-то наткнутся на эту тему, как и я.

len ('blah blah' + '.') - 1

Ответ 6

К сожалению, нет идеального решения, о котором я знаю.

Одно из предложенных решений, LEN(string + '.')-1 возвращает неверные результаты (-1), если строка имеет Unicode размера 4000 или не Unicode и размера 8000. Это происходит потому, что объединение игнорируется. Вы можете преодолеть это, если хотите, приведя строку к строке размера MAX: LEN(CAST(string as nvarchar(max)) + '.')-1, но стоит ли это того?

Как уже упоминалось, DATALENGTH(string) возвращает количество байтов, используемых для хранения. Для строк Unicode может быть недостаточно разделить результат на 2: суррогатные символы Unicode могут занимать более 16 бит.

В общем, помните об ограничениях каждого подхода и выбирайте то, во что вы верите, вызовет у вас меньше проблем.