|
Now you are shooting blanks
modified 19-Nov-18 21:01pm.
|
|
|
|
|
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! 
|
|
|
|
|
One of the hazards of being the UI guy, and all of your UI's are localized - you can make UNICODE jokes  .
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.
|
|
|
|
|
2, he said. Snicker, chortle, guffaw. 
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;
|
|
|
|
|
Chris Maunder wrote: Hands up who has ever noticed the "excluding trailing blanks" bit?
Me.
It amazed me the first time I discovered it as well. I only figured it out after trying to figure out why some code was failing to behave as it should.
I added documentation to the stored procedure to clearly call it out, so the next developer (perhaps even me) would not be surprised either.
I believe, but I could be mistaken, it only applies to a the data type 'char'. Your constant is a 'char'. It behaves as expected with 'varchar'.
|
|
|
|
|
I wonder if this has anything to do with CHAR is fixed length and VARCHAR is variable length?
modified 27-Sep-17 15:53pm.
|
|
|
|
|
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  .
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.
|
|
|
|
|
Jan Holst Jensen2 wrote: Yup. I know this is a question about SQL Server, but I have a feeling that they have adopted some old logic from Oracle.
Could be. The timeline makes it possible. Sybase (precursor to SQL Server) was founded after Oracle.
|
|
|
|
|
If this was QA, I'd be fighting the urge - a strong urge - to reply "RTFM".
But it isn't, so I don't have to... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
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
|
|
|
|
|
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 "<language> 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?
The more I learn about TSQL, the more I enjoy the fact the most of the bigger companies use Oracle DB... 
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
|
|
|
|
|
SELECT DATALENGTH(' ');
> 5
|
|
|
|
|
Sooo... there are probably other things for which you have not yet RTFMed?
modified 29-Sep-17 16:57pm.
|
|
|
|
|
Does this scare you? 
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
|
|
|
|
|
|
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. 
|
|
|
|
|
In a DB that blank pads all columns to their fixed size, this really makes sense.
LEN (Transact-SQL) | Microsoft Docs
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
