July 11, 2013 at 9:16 am
Kingston Dhasian (7/11/2013)
Bajrang (7/11/2013)
Thank you SSC for posting this question.. 🙂and
Thank you all members.. Yes, explanation provided on BOL link doesn't fit but couldn't find any other source to support this. 😀
The explanation provided in BOL is correct. Check the block Truncating and Rounding Results in the link you have provided.
Yes, but the wording of the BOL page is really confusing, in fact it could reasonably be thought bad enough to be either incorrect English, or technically incorrect - which sort (linguistic or technical) of incorrectness depends on what you think the page's author was trying to say. "The result is too short to display" - what result? The result of the conversion here is a single *, so yes it's a very short string, but ssms will have no difficulty in displaying it. If he is trying to say something technically correct (which most BOL page authors usually are) he must mean "the result of converting to a string is too long to display as the type specified in the function call" or "the type provided for the result does not provide enough space to hold the result of converting the argument to a string" or perhaps "the result of conversion to string is too long to hold as a value of the type specified for the result of the function call" or some other way of stating what actually happens. It would actually improve the text just to replace "too short" by "too long" but that would not make it fully right since it would still suffer the ambiguity of the meaning of "the result", which could either be the result of the call to the built in function convert or the result of conversion of the value to a string - the second of those is indeed too long, but the first isn't; while neither is too short, which is why "too long" would be a bit better than "too short". I suspect the BOL page author though that "result" could refer to the first argument of the function, which is of course an error of language.
So I think Bajrang is actually right when he says the explanation on the BOL link doesn't fit - it's a pity that in trying to get the correct explanation he got it wrong, but at least he spotted that BOL was wrong and didn't reproduce its error.
Tom
July 11, 2013 at 9:28 am
Thank you Tom.. 🙂
July 11, 2013 at 9:32 am
<sarcasm>
I don't think I understand entirely how the explanation was wrong. Can someone else (or maybe 10 more people) please chime in and explain exactly what was so incorrect about it? :hehe:
</sarcasm>
July 11, 2013 at 10:28 am
Bajrang (7/10/2013)
Comments posted to this topic are about the item <A HREF="/questions/Convert/100444/">What will convert return?</A>
Good Question but your explination nees work.
declare @value int
set @value = 2147483647
PRINT @value
PRINT CONVERT(varchar(6), @value)
set @value = 5555555
PRINT @value
PRINT CONVERT(varchar(6), @value)
This code shows that your explination does not fit the actual symptom.
What you shold have said that if the Length of the INT value is greater than the length of the string value an * is returned instead of a truncated string or error.
Always checks lengths prior to conversion into length limited formats.
Or declare a string value that will contain max Integer values characters i.e. varchar(12)
July 11, 2013 at 10:29 am
Jeff Moden (7/11/2013)
Even though the explanation of exceeding the max INT value is completely wrong, I'm absolutely amazed that more than 1/3 of the people that answered this question got it wrong.
As we all are Jeff.
July 11, 2013 at 10:35 am
L' Eomot Inversé (7/11/2013)Yes, but the wording of the BOL page is really confusing, in fact it could reasonably be thought bad enough to be either incorrect English, or technically incorrect - which sort (linguistic or technical) of incorrectness depends on what you think the page's author was trying to say. "The result is too short to display" - what result? The result of the conversion here is a single *, so yes it's a very short string, but ssms will have no difficulty in displaying it.........
"Every BOL article on odd TSQL behavior ever written fits this descrition."
It's almost like they want us to create sites like this.
Like we are encoraged and given reason and value for our own blogs and books.
Like they actually made parts of the language and it's documentaion so that it needs to be learned and tested to be executed properly.
😎 hrmmmmmmm
July 11, 2013 at 5:40 pm
PHYData DBA (7/11/2013)
L' Eomot Inversé (7/11/2013)Yes, but the wording of the BOL page is really confusing, in fact it could reasonably be thought bad enough to be either incorrect English, or technically incorrect - which sort (linguistic or technical) of incorrectness depends on what you think the page's author was trying to say. "The result is too short to display" - what result? The result of the conversion here is a single *, so yes it's a very short string, but ssms will have no difficulty in displaying it.........
I read this and think.."Every BOL article on odd TSQL behavior ever written fits this descrition."
It's almost like they want us to create sites like this.
Like we are encoraged and given reason and value for our own blogs and books.
Like they actually made parts of the language and it's documentaion so that it needs to be learned and tested to be executed properly.
😎 hrmmmmmmm
It's an interesting theory, but I don't think the author's of BOL are quite clever enough to play that trick. I could be wrong, of course, but like the BOL authors I have written rather badly now and again and most of the time it was without any motivation such as you suggest (and some of the other times are a source of embarrassment, I must remember to insert suitable emoticons when spouting complete drivel :ermm:) :laugh:.
Tom
July 11, 2013 at 7:38 pm
L' Eomot Inversé (7/11/2013)
PHYData DBA (7/11/2013)
L' Eomot Inversé (7/11/2013)Yes, but the wording of the BOL page is really confusing, in fact it could reasonably be thought bad enough to be either incorrect English, or technically incorrect - which sort (linguistic or technical) of incorrectness depends on what you think the page's author was trying to say. "The result is too short to display" - what result? The result of the conversion here is a single *, so yes it's a very short string, but ssms will have no difficulty in displaying it.........
I read this and think.."Every BOL article on odd TSQL behavior ever written fits this descrition."
It's almost like they want us to create sites like this.
Like we are encoraged and given reason and value for our own blogs and books.
Like they actually made parts of the language and it's documentaion so that it needs to be learned and tested to be executed properly.
😎 hrmmmmmmm
It's an interesting theory, but I don't think the author's of BOL are quite clever enough to play that trick. I could be wrong, of course, but like the BOL authors I have written rather badly now and again and most of the time it was without any motivation such as you suggest (and some of the other times are a source of embarrassment, I must remember to insert suitable emoticons when spouting complete drivel :ermm:) :laugh:.
BOL writers are humans, too, and most of them are in India and paid $5 per day.
Kudos to Rupesh for this QotD!
July 12, 2013 at 12:11 pm
Revenant (7/11/2013)
BOL writers are humans, too, and most of them are in India and paid $5 per day.
well, that's about 300 Rupees, which is about 3 times what it used to cost me to get very three good meals (breakfast, lunch, dinner) in middle class restaurants in Chennai a few years ago, so it's not as little as it sounds to anyone used to American or Western European pay rates - you have to correct for cost of living.
Kudos to Rupesh for this QotD!
Yes, I agree, particularly since he did recognise that the words in BOL were wrong.
Tom
July 15, 2013 at 1:11 am
L' Eomot Inversé (7/11/2013)
Kingston Dhasian (7/11/2013)
Bajrang (7/11/2013)
Thank you SSC for posting this question.. 🙂and
Thank you all members.. Yes, explanation provided on BOL link doesn't fit but couldn't find any other source to support this. 😀
The explanation provided in BOL is correct. Check the block Truncating and Rounding Results in the link you have provided.
Yes, but the wording of the BOL page is really confusing, in fact it could reasonably be thought bad enough to be either incorrect English, or technically incorrect - which sort (linguistic or technical) of incorrectness depends on what you think the page's author was trying to say. "The result is too short to display" - what result? The result of the conversion here is a single *, so yes it's a very short string, but ssms will have no difficulty in displaying it. If he is trying to say something technically correct (which most BOL page authors usually are) he must mean "the result of converting to a string is too long to display as the type specified in the function call" or "the type provided for the result does not provide enough space to hold the result of converting the argument to a string" or perhaps "the result of conversion to string is too long to hold as a value of the type specified for the result of the function call" or some other way of stating what actually happens. It would actually improve the text just to replace "too short" by "too long" but that would not make it fully right since it would still suffer the ambiguity of the meaning of "the result", which could either be the result of the call to the built in function convert or the result of conversion of the value to a string - the second of those is indeed too long, but the first isn't; while neither is too short, which is why "too long" would be a bit better than "too short". I suspect the BOL page author though that "result" could refer to the first argument of the function, which is of course an error of language.
I didn't know it can be taken this way. But, you are right in saying that the statements can confuse people.
I didn't get confused probably because I was aware of the behavior before reading the explanation.
I said what I felt and I never intended to discourage Rupesh. Kudos to Rupesh from my side for his QOTD 🙂
How to post data/code on a forum to get the best help - Jeff Moden
http://www.sqlservercentral.com/articles/Best+Practices/61537/
July 15, 2013 at 1:18 am
Revenant (7/11/2013)
BOL writers are humans, too, and most of them are in India and paid $5 per day.
Even I don't think it's about the money. You can get people with really good English for that amount.
Its probably because the authors( people who type it for 5$ per day ) don't have a programming background to understand terms like length, result, functions, etc.
How to post data/code on a forum to get the best help - Jeff Moden
http://www.sqlservercentral.com/articles/Best+Practices/61537/
July 16, 2013 at 5:34 am
nice confussion question...:-)
Manik
You cannot get to the top by sitting on your bottom.
July 16, 2013 at 9:30 am
L' Eomot Inversé (7/11/2013)
It's an interesting theory, but I don't think the author's of BOL are quite clever enough to play that trick. I could be wrong, of course, but like the BOL authors I have written rather badly now and again and most of the time it was without any motivation such as you suggest (and some of the other times are a source of embarrassment, I must remember to insert suitable emoticons when spouting complete drivel :ermm:) :laugh:.
I sure hope you where able to interpret some Humor in what I wrote.
The Books Online for most products have lots of errors and issues.
I like the fact that the current ones allow you to post on the same page when you want to put something important to share with the community.
Have Fun with all your opinions!! :hehe::-P:-D:w00t:
July 24, 2013 at 12:45 am
Koen Verbeeck (7/11/2013)
Good question, oldie but a goodie.Explanation however is incorrect. The problem is not that the value exceeds the upper limit of an integer , I'm pretty sure 5555555 can fit in an integer, but the problem is that the string 5555555 is 7 characters long and you're trying to convert it to 6 characters. This will lead to a truncation, which for some data types will give * when using the CONVERT function.
Good explanation. 5555555 can definitely fit in the int datatype. It's the conversion to varchar(6) which causes issue. If it was varhcar(7), it would have returned the value 5555555.
July 25, 2013 at 10:05 am
Thanks for the ¿
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply