Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

Arithmetic 1 Expand / Collapse
Author
Message
Posted Wednesday, February 29, 2012 3:09 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 5:25 AM
Points: 1,696, Visits: 1,114
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.
Post #1259378
Posted Wednesday, February 29, 2012 3:24 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen 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.
Post #1259391
Posted Wednesday, February 29, 2012 3:59 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 12:19 AM
Points: 302, Visits: 179
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.
Post #1259412
Posted Wednesday, February 29, 2012 4:17 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 11:29 AM
Points: 2,734, Visits: 939
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.
Post #1259421
Posted Wednesday, February 29, 2012 4:28 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Saturday, August 30, 2014 9:14 AM
Points: 1,258, Visits: 13,554
good question!!!
thanks Ron!!!



rfr.ferrari
DBA - SQL Server 2008
MCITP | MCTS

remember is live or suffer twice!
Post #1259425
Posted Wednesday, February 29, 2012 5:31 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 10:35 AM
Points: 1,825, Visits: 2,175
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.
Connect to me on LinkedIn
Post #1259474
Posted Wednesday, February 29, 2012 6:03 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 2, 2014 7:18 AM
Points: 1,369, Visits: 1,314
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
Post #1259497
Posted Wednesday, February 29, 2012 6:39 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 12:53 AM
Points: 2,529, Visits: 2,402
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

Post #1259521
Posted Wednesday, February 29, 2012 7:29 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:36 PM
Points: 6,002, Visits: 8,267
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
Post #1259552
Posted Wednesday, February 29, 2012 7:37 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 2:58 PM
Points: 3,799, Visits: 1,176
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

To better understand your help request, please follow these best practices.
Post #1259562
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse