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

differences in rounding / converting strings Expand / Collapse
Author
Message
Posted Monday, December 9, 2013 9:11 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, July 4, 2014 4:32 AM
Points: 152, Visits: 386
Hi all,

first of all: I know some best practices and work-arounds when working with float numbers, I just want to understand :)

An older topic tried to explain the difference between
SELECT ROUND ('6.465',2) --- result 6.46

and
SELECT ROUND (6.465,2) --- result 6.47

with

It's because you're relying on an implicit conversion from a string to a decimal data type which SQL server will do to 2 decimal places by default...


Allright:

SELECT ROUND (CONVERT(DECIMAL(3,2),'6.465'),2) --- result 6.47

Now please explain this:
SELECT ROUND('0.285',2)  -- 0.28
SELECT ROUND(0.285,2) -- 0.29
SELECT ROUND (CONVERT(DECIMAL(3,2),'0.285'),2) --- result 0.29

The string value does not seem to be converted to decimal with 2 decimal places.

MS is on the safe side with mentioning
the last digit is always an estimate

But because the result of the estimate is always the same, I would like to know:

* how is a string value exactly implicitly converted?
* how exactly does the estimation work, that in case of doubt rounds a value up or off?

Thank You!
Post #1521173
Posted Tuesday, December 10, 2013 10:43 PM


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: Today @ 4:14 AM
Points: 3,618, Visits: 5,254
The last thing I want to try to do is explain the implicit conversion rules SQL chooses to use in these kinds of cases.

Your best bet is to CAST the VARCHAR to a DECIMAL type explicitly and then do the rounding, so that there is no ambiguity with respect to what the result will be.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1521741
Posted Wednesday, December 11, 2013 2:33 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, July 4, 2014 4:32 AM
Points: 152, Visits: 386
Thank you Dwain,

yep, I hoped someone could explain the implicit conversion rules...
Post #1521784
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse