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 123»»»

cast, convert and float! Expand / Collapse
Author
Message
Posted Thursday, August 20, 2009 12:08 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, July 23, 2013 6:34 AM
Points: 654, Visits: 265
Comments posted to this topic are about the item cast, convert and float!
Post #774016
Posted Thursday, August 20, 2009 1:03 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, October 24, 2011 8:19 AM
Points: 340, Visits: 85
Hi, the question has a misprint, probably intended:
select @d = cast(convert(varchar(2),convert(varchar(3),@c)) as float) * 0.5
select @d
Post #774033
Posted Thursday, August 20, 2009 5:19 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
Probably should use SET vs. SELECT. Think I saw that as being deprecated, but I might be wrong?
Post #774121
Posted Thursday, August 20, 2009 7:09 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Tuesday, March 29, 2011 2:59 PM
Points: 473, Visits: 606
Scary part is over 30% (at the time of this post) got it wrong. Many QoDs are quite tricky but this one is very basic and really not SQL specific (data type conversion or casting is an ABC of any programming language).
Looks like a concept of code review or inspection is missing way too often...


---------------------------------------------
Nothing is impossible.
It is just a matter of time and money.
Post #774173
Posted Thursday, August 20, 2009 7:14 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 10:25 AM
Points: 1,908, Visits: 2,060
I think the 30% of us (me included) that got it wrong just need to make sure we get our morning caffiene before trying to answer the questions
Post #774176
Posted Thursday, August 20, 2009 7:26 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 6:08 AM
Points: 77, Visits: 169
Mark Horninger (8/20/2009)
Probably should use SET vs. SELECT. Think I saw that as being deprecated, but I might be wrong?

I was on that in another discussion. It doesn't say "deprecated", it does say "we recommend you don't use it", and no one knew why. Is SQL Server 7.0 or earlier around anywhere so we could see whether at any time it was announced deprecated? Or did we already do that?

I put the wrong answer, 10.5, I missed that the calculation result was stored back to the int variable(!)

Two thoughts on these exercises generally:

1. Often you look at the puzzle code and go "But you wouldn't do it that way!" But 1a, that isn't the point. And, 1b, the way "you" would do it may be different from the way "that guy who wrote some stuff for us till we found out he was raised by squirrels from birth and not a real MSCE at all" would do it. Some people do write squirrelly code.

A co-worker just couldn't read a query of mine yesterday, so there is something wrong with at least one of us, him and/or me!

2. If you only go in on the questions you think you know, and skip the harder ones, it skews the scoreboard. But 2a, who cares.
Post #774189
Posted Thursday, August 20, 2009 7:34 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
rja.carnegie (8/20/2009)
Mark Horninger (8/20/2009)
Probably should use SET vs. SELECT. Think I saw that as being deprecated, but I might be wrong?

I was on that in another discussion. It doesn't say "deprecated", it does say "we recommend you don't use it", and no one knew why. Is SQL Server 7.0 or earlier around anywhere so we could see whether at any time it was announced deprecated? Or did we already do that?

I put the wrong answer, 10.5, I missed that the calculation result was stored back to the int variable(!)

Two thoughts on these exercises generally:

1. Often you look at the puzzle code and go "But you wouldn't do it that way!" But 1a, that isn't the point. And, 1b, the way "you" would do it may be different from the way "that guy who wrote some stuff for us till we found out he was raised by squirrels from birth and not a real MSCE at all" would do it. Some people do write squirrelly code.

A co-worker just couldn't read a query of mine yesterday, so there is something wrong with at least one of us, him and/or me!

2. If you only go in on the questions you think you know, and skip the harder ones, it skews the scoreboard. But 2a, who cares.



HEre's what I found - Set Vs. Select

http://ryanfarley.com/blog/archive/2004/03/01/390.aspx

http://vyaskn.tripod.com/differences_between_set_and_select.htm

Post #774196
Posted Thursday, August 20, 2009 7:37 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Tuesday, March 29, 2011 2:59 PM
Points: 473, Visits: 606
A co-worker just couldn't read a query of mine yesterday, so there is something wrong with at least one of us, him and/or me!


Maybe both of you are quite OK and the missing part is good comments in the code...

Sometimes I write some SQL code I can not figure out myself few weeks later if I do not comment it correctly.


---------------------------------------------
Nothing is impossible.
It is just a matter of time and money.
Post #774200
Posted Thursday, August 20, 2009 8:12 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:53 PM
Points: 2,392, Visits: 2,786
I just plain got it wrong because of the int @c, after focusing too much on confirming the 21 * 0.5 calculation. Good question in that it highlights rookie mistakes I shouldn't be making....

Thanks,
webrunner


-------------------
"Operator! Give me the number for 911!" - Homer Simpson

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Post #774234
Posted Thursday, August 20, 2009 8:56 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 6:55 AM
Points: 880, Visits: 876
I also missed the assignment back to the int variable. Oops. It would have been an obvious answer if only I'd paid better attention.

SELECTing into a variable is not being deprecated. But there are a few things to know when deciding whether to use SET or SELECT:

1) SET is the ANSI standard for assigning variable values. So if you care about that, there's your answer.

2) When assigning a value from a query, SET will raise an error if multiple rows are returned. SELECT will simply assign the last returned value and go about its merry way.

3) If the query returns zero rows, SET will set the variable to NULL. SELECT will leave the variable set to its current value.

4) SELECT can assign values to multiple variables simultaneously. So if you have three variables that each need a value from a given table, you'd have to query the table three times using SET, and only once with SELECT. Obviously this would have performance benefits in certain scenarios.

The conventional wisdom, as far as my research indicates, is that SELECT is preferable when you need to set multiple variables from a single query. SET is preferable when setting a single variable, or if ANSI-compliance is a requirement.

Ron Moses


-----
a haiku...

NULL is not zero
NULL is not an empty string
NULL is the unknown
Post #774295
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse