SQL does my head in
-
This is the point: I've read the manual a million times. And I never noticed the proviso. What kills me, I think (apart from noisy bagpipes and people who don't indicate when turning) is that they've taken a method (LEN) that is used everywhere for the same thing - get the length of something - and bent it slightly. The length of something except for a bit at the end, sometimes. I propose that we, immediately, rename DATALENGTH to LEN, and LEN to LENWITHOUTTHETRAILINGSPACES, and to hell with the destruction this will cause to civilisation.
cheers Chris Maunder
Or, I dunno, embrace object databases as a profession. Just saying.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
And you will only make that mistake twice: For the first and the last time. :-)
I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins.
Human being is the only animal that stumble twice with the same stone
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I see 2 trailing blanks and 2 leading blanks surrounding a single blank.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
Hmm. Actually, there could be an infinite number of zero width spaces[^] in that string in addition to the 'normal' spaces, if you're using UNICODE.
Software Zen:
delete this; -
Hmm. Actually, there could be an infinite number of zero width spaces[^] in that string in addition to the 'normal' spaces, if you're using UNICODE.
Software Zen:
delete this;Dear lord! :eek:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
Dear lord! :eek:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
One of the hazards of being the UI guy, and all of your UI's are localized - you can make UNICODE jokes :sigh:.
Software Zen:
delete this; -
One of the hazards of being the UI guy, and all of your UI's are localized - you can make UNICODE jokes :sigh:.
Software Zen:
delete this;:laugh:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
This is the point: I've read the manual a million times. And I never noticed the proviso. What kills me, I think (apart from noisy bagpipes and people who don't indicate when turning) is that they've taken a method (LEN) that is used everywhere for the same thing - get the length of something - and bent it slightly. The length of something except for a bit at the end, sometimes. I propose that we, immediately, rename DATALENGTH to LEN, and LEN to LENWITHOUTTHETRAILINGSPACES, and to hell with the destruction this will cause to civilisation.
cheers Chris Maunder
Holy crap, I propose T-SQL gets killed and replaced with ANSI SQL... I've been working with enterprise databases for almost 15 years now (plus a few more in general programming) and never have I ever read a manual for a string length function! You just google " string lenght" and notice the snippet of the first post "select len(mycol) from.." and there you go, you know it. I would NEVER expect a len() to function as len(rtrim())... that's just insane; any other programming languages do this sort of (sorry, but it is...) idiotic thing? :wtf: The more I learn about TSQL, the more I enjoy the fact the most of the bigger companies use Oracle DB... :-O Maybe next time I get a client with MS (so rare, w00t), I'm really gonna have to RT(whole)FM, even for very standard functions like len()!!?!? Insane, I tell you! Maybe I'll find that substr() doesn't consider ponctuation or something...??
-
I wonder if this has anything to do with CHAR is fixed length and VARCHAR is variable length?
Slacker007 wrote:
I wonder if this has anything to do with CHAR is fixed length and VARCHAR is variable length?
Yup. I know this is a question about SQL Server, but I have a feeling that they have adopted some old logic from Oracle. In Oracle the CHAR type will automatically pad data with spaces so the data field always occupies the max length you specified. CHAR versus VARCHAR2 Semantics[^] In that context, the behavior of len() is actually the only one that makes sense :wtf: . So, to keep your sanity you never want to use CHAR but always VARCHAR/VARCHAR2 :-). Or, in Postgres - just use TEXT to get rid of all those pesky length constraints as well.
-
LEN (Transact-SQL) Returns the number of characters of the specified string expression, excluding trailing blanks So
> print len('hello')
5
and
> print len(' ')
0
Hands up who has ever noticed the "excluding trailing blanks" bit? Up until an hour ago, not me. Which boggles my mind.
cheers Chris Maunder
Me! Just recently I had the same issue. My workaround was to use a replace function and then get the length of that string.
AND LEN(REPLACE(FieldWithValue, ' ', '*')) = 11
Later on I used
Datalength
-
LEN (Transact-SQL) Returns the number of characters of the specified string expression, excluding trailing blanks So
> print len('hello')
5
and
> print len(' ')
0
Hands up who has ever noticed the "excluding trailing blanks" bit? Up until an hour ago, not me. Which boggles my mind.
cheers Chris Maunder
Pffffst! Human!
-
LEN (Transact-SQL) Returns the number of characters of the specified string expression, excluding trailing blanks So
> print len('hello')
5
and
> print len(' ')
0
Hands up who has ever noticed the "excluding trailing blanks" bit? Up until an hour ago, not me. Which boggles my mind.
cheers Chris Maunder
For those who reply RTFM... I believe it would be far more cost effective to just allow the ensuing bug to be reported by the end user and fix it then. ;P
-
Hmm. Actually, there could be an infinite number of zero width spaces[^] in that string in addition to the 'normal' spaces, if you're using UNICODE.
Software Zen:
delete this;You can't do that without IBM's new Infinite Storage. But they're in short supply. Their first customer ordered two.
-
You can't do that without IBM's new Infinite Storage. But they're in short supply. Their first customer ordered two.
2, he said. Snicker, chortle, guffaw. :-D
Software Zen:
delete this; -
LEN (Transact-SQL) Returns the number of characters of the specified string expression, excluding trailing blanks So
> print len('hello')
5
and
> print len(' ')
0
Hands up who has ever noticed the "excluding trailing blanks" bit? Up until an hour ago, not me. Which boggles my mind.
cheers Chris Maunder
In a DB that blank pads all columns to their fixed size, this really makes sense. [LEN (Transact-SQL) | Microsoft Docs](https://docs.microsoft.com/en-us/sql/t-sql/functions/len-transact-sql) snip Remarks LEN excludes trailing blanks. If that is a problem, consider using the
DATALENGTH(Transact-SQL) function which does not trim the string. If processing a unicode string, DATALENGTH will return twice the number of characters. The following example demonstrates LEN and DATALENGTH with a trailing space. -
LEN (Transact-SQL) Returns the number of characters of the specified string expression, excluding trailing blanks So
> print len('hello')
5
and
> print len(' ')
0
Hands up who has ever noticed the "excluding trailing blanks" bit? Up until an hour ago, not me. Which boggles my mind.
cheers Chris Maunder
-
In a DB that blank pads all columns to their fixed size, this really makes sense. [LEN (Transact-SQL) | Microsoft Docs](https://docs.microsoft.com/en-us/sql/t-sql/functions/len-transact-sql) snip Remarks LEN excludes trailing blanks. If that is a problem, consider using the
DATALENGTH(Transact-SQL) function which does not trim the string. If processing a unicode string, DATALENGTH will return twice the number of characters. The following example demonstrates LEN and DATALENGTH with a trailing space.Yes - I understand the function and how it works. My point was that I'd missed that tiny little proviso. For years. It shocked me. Storing padding data inside a database? Please no. That's awful.
cheers Chris Maunder
-
Holy crap, I propose T-SQL gets killed and replaced with ANSI SQL... I've been working with enterprise databases for almost 15 years now (plus a few more in general programming) and never have I ever read a manual for a string length function! You just google " string lenght" and notice the snippet of the first post "select len(mycol) from.." and there you go, you know it. I would NEVER expect a len() to function as len(rtrim())... that's just insane; any other programming languages do this sort of (sorry, but it is...) idiotic thing? :wtf: The more I learn about TSQL, the more I enjoy the fact the most of the bigger companies use Oracle DB... :-O Maybe next time I get a client with MS (so rare, w00t), I'm really gonna have to RT(whole)FM, even for very standard functions like len()!!?!? Insane, I tell you! Maybe I'll find that substr() doesn't consider ponctuation or something...??
Exactly!
cheers Chris Maunder
-
Hmm. Actually, there could be an infinite number of zero width spaces[^] in that string in addition to the 'normal' spaces, if you're using UNICODE.
Software Zen:
delete this; -
don't even get me started on that. I have been burned so many times on the zero length spaces. They are very spacey
To err is human to really mess up you need a computer
rnbergren wrote:
I have been burned so many times on the zero length spaces
I actually found a good use for them. I had a comma-separated value file I was dealing with, and I didn't want embedded line breaks. I replaced the line breaks with zero-width spaces, and voila! As I recall, even Excel handled them correctly.
Software Zen:
delete this; -
Slacker007 wrote:
I wonder if this has anything to do with CHAR is fixed length and VARCHAR is variable length?
Yup. I know this is a question about SQL Server, but I have a feeling that they have adopted some old logic from Oracle. In Oracle the CHAR type will automatically pad data with spaces so the data field always occupies the max length you specified. CHAR versus VARCHAR2 Semantics[^] In that context, the behavior of len() is actually the only one that makes sense :wtf: . So, to keep your sanity you never want to use CHAR but always VARCHAR/VARCHAR2 :-). Or, in Postgres - just use TEXT to get rid of all those pesky length constraints as well.