|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 2:26 AM
Points: 1,084,
Visits: 690
|
|
Carlo Romagnano (2/29/2012) This kind of error also is independent from version of sqlserver. You can not use - * / operators with chars
Well, you obviously can - as long as one of the other operators is a numeric type, so that SQL can decide what to attempt to convert the chars to. That's the level of guidance that SQL expects and it seems a decent compromise, rather than just making it so it will attempt a conversion to a non-specified type.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Thursday, January 24, 2013 9:59 PM
Points: 1,354,
Visits: 1,299
|
|
Raghavendra Mudugal (2/29/2012) It gives me this error on the 2nd block
Msg 8117, Level 16, State 1, Line 3 Operand data type char is invalid for multiply operator.
I guess E stands for ERROR?
You wouldn't have had to guess if you read the statement after the SQL:
For simplity in creating the possible answers each answer is composed of a comma separated list and if execution of one of the above generates an error the letter E will be included in the list.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Thursday, April 11, 2013 5:56 AM
Points: 245,
Visits: 147
|
|
I would thing the devil were in the details. In fact a lot of the questions would fail if not for the fact that the numeric in the question is in fact a numeric. The trap, if we can call it that, is that no none-character values were there to coax the cast. If #2 had been constructed like the others, thus having the number '4' as a number in stead of a string, the statement would have done the cast and no error would have followed. Inserting a character i e.g. #4 would of course cause that one to fail as well.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 2:15 PM
Points: 1,176,
Visits: 674
|
|
I'm pretty sure SQL ill not multiply chars '1' * '4' it demands at least one numeric type to decide for the result type.
Yes! Implicit convertion is evil. Even worst when converting dates and using fancy collations and no US-en.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Thursday, May 02, 2013 10:51 AM
Points: 1,219,
Visits: 13,507
|
|
good question!!! thanks Ron!!!
rfr.ferrari DBA - SQL Server 2008 MCITP | MCTS
remember is live or suffer twice!
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 5:02 AM
Points: 1,149,
Visits: 1,451
|
|
Excellent question. Code parsing for a reason, with clear explanation. Thanks bitbucket!
Please don't go. The drones need you. They look up to you.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 6:14 AM
Points: 1,102,
Visits: 1,197
|
|
jcb (2/29/2012) Yes! Implicit convertion is evil. Even worst when converting dates and using fancy collations and no US-en. Fancy collations Tomorow morning in Bois de Boulogne
See, understand, learn, try, use efficient © Dr.Plch
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Yesterday @ 12:54 AM
Points: 1,969,
Visits: 1,820
|
|
This script demonstrates some problem with implicit conversion:
declare @v varchar(30) ,@f float
-- here you think it is all right and it is set @f = 1.12 set @v = @f select @v -- here you think it is all right, but you get the wrong result set @f = 123456.12 set @v = @f select @v -- worst and worst set @f = 12345677.12 set @v = @f select @v -- correct solution set @f = 12345677.12 set @v = CAST(@f AS DECIMAL(16,2)) select @v
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 4:30 PM
Points: 5,235,
Visits: 7,038
|
|
I could not locate a valid explanation And hyet, the explanation is simple. I lack the time to find the proper Books Online pages at this time, but they are in fact easy to find.
In five out of six batches, one operand is a character value and the other is an integer value. The rules of data type precedence specify (look up: "Data type precedence" in books online) that in such a case, the character operand (lower precedence) is converted to int (higher precedence) before the operator is invoked. The operator then operates on two integer values.
In the batch that errors, both operands are string. No data type conversion is required, and the operator is invoked. If the operator would have been +, that would have resulted in string concatenation. But the operator * is undefined for string operands. So, no bugs, no incorrect answer; SQL Server is operating is intended and as documented.
Overall a good question, but a disappointing explanation. Also, the subtle differences in the form of the batches made it harder to see what was going on. I almost jumped to the conclusion that all batches combined an int and a char value; the only reason that I continued to lkook deeper was that I figured that there had to be a catch somewhere. With u uniform format for all the questions, it would have been easier to spot the differences and focus on the skill the question indended to test.
Hugo Kornelis, SQL Server MVP Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Thursday, May 02, 2013 3:45 PM
Points: 3,748,
Visits: 928
|
|
Thank you for the question!! I agree with all others that having at least one numeric causes implicit conversion for the char values, but 2 chars cannot be multiplied.
Yes, we have to be very careful with implicit conversion.
I remember in VAX VMS BASIC you could do operations with numbers as chars, and they had a much higher precision that numeric data types (e.g. I was able to calculate PI with over 100 decimals), that was long ago, and I haven't seen any other language have this feature.
"El" Jerry.
"El" Jerry.
"A watt of Ottawa" - Gerardo Galvan
|
|
|
|