

Grasshopper
Group: General Forum Members
Last Login: Saturday, March 7, 2015 6:33 AM
Points: 13,
Visits: 14


sometimes float values are returned as "0E7" instead of "0.0000000" or "4E7" instead of "0.0000004"  is there some formatting statement or other method to prevent this?
Michael




Mr or Mrs. 500
Group: General Forum Members
Last Login: Friday, July 22, 2016 8:58 AM
Points: 567,
Visits: 1,274


Nops.. that how SQL stores and retrieves the data... If you don't want that behavior don't where floating point data types, use DECIMAL. there's an article explaining why floating point numbers can be a problem... http://docs.oracle.com/cd/E1995701/8063568/ncg_goldberg.html.
If you need to work better, try working less...




Grasshopper
Group: General Forum Members
Last Login: Saturday, March 7, 2015 6:33 AM
Points: 13,
Visits: 14


thanks for the quick reply ... can I simply change the data types in the table design view? will the data that are already in there stay unharmed by this change?
Michael




SSCrazy
Group: General Forum Members
Last Login: Friday, July 15, 2016 2:34 PM
Points: 2,599,
Visits: 3,382


veloopity (12/17/2012) thanks for the quick reply ... can I simply change the data types in the table design view? will the data that are already in there stay unharmed by this change?
Michael
That depends on exactly what you change them to, and the existing values. For existing values that are integers, there's no loss of accuracy, but for any noninteger value, you can lose considerable precision if the number of decimal places you specify is small enough, and/or the level of accuracy needed is high enough. As an example, if you use a given field to represent an amount of money, and the smallest division of the money amount would result in at most 2 digits to the right of the decimal, AND, you know beyond all doubt that your data conforms, then you can use a SCALE of 2 without a problem. On the other hand, if you need to represent scientific data or measurements of some kind, moving away from float could have serious consequences for statistical measures or other group calculations. Unfortunately, you'll need to review the usage and representation for every field for which you contemplate a change.
Without considerably more detail, we'd have great difficulty providing much more than generalities... which may or may not apply to your situation.
Steve (aka sgmunson)
Health & Nutrition




Grasshopper
Group: General Forum Members
Last Login: Saturday, March 7, 2015 6:33 AM
Points: 13,
Visits: 14


> sometimes float values are returned as "0E7" instead of "0.0000000" or "4E7" instead of "0.0000004"
what is the rule then ... when are numbers displayed like that and when not?
m




SSCAddicted
Group: General Forum Members
Last Login: Wednesday, January 16, 2013 4:23 PM
Points: 415,
Visits: 2,333


veloopity (12/18/2012) > sometimes float values are returned as "0E7" instead of "0.0000000" or "4E7" instead of "0.0000004"
what is the rule then ... when are numbers displayed like that and when not?
m
I don't know the rules, I suspect that if the number of places to either the left or right of the '.' exceed some limit, the various clients that display floating point from SQL servers will fall back to scientific notation. SSMS seems to be rather sensitive to places to the right of the decimal point, not so much to the left.
I like to use CONVERT for on the fly formatting, but check out some of the interesting results when using it. These not exactly right representations happen because you cannot represent some numbers exactly in internal binary (base 2) formats like floating point, that you could otherwise spec exactly in base 10 numbering systems.
CREATE TABLE #T (T1 FLOAT) INSERT INTO #T (T1) SELECT 0.000001 INSERT INTO #T (T1) SELECT 0.00001 INSERT INTO #T (T1) SELECT 0.0001 INSERT INTO #T (T1) SELECT 0.001 INSERT INTO #T (T1) SELECT 0.01 INSERT INTO #T (T1) SELECT 0.1 INSERT INTO #T (T1) SELECT 1. INSERT INTO #T (T1) SELECT 10 INSERT INTO #T (T1) SELECT 100 INSERT INTO #T (T1) SELECT 1000 INSERT INTO #T (T1) SELECT 10000 INSERT INTO #T (T1) SELECT 100000 INSERT INTO #T (T1) SELECT 1000000 INSERT INTO #T (T1) SELECT 10000000 INSERT INTO #T (T1) SELECT 100000000 INSERT INTO #T (T1) SELECT 1000000000 INSERT INTO #T (T1) SELECT 10000000000 INSERT INTO #T (T1) SELECT 100000000000 INSERT INTO #T (T1) SELECT 1000000000000 INSERT INTO #T (T1) SELECT 1.1 INSERT INTO #T (T1) SELECT 10.1 INSERT INTO #T (T1) SELECT 100.1 INSERT INTO #T (T1) SELECT 1000.1 INSERT INTO #T (T1) SELECT 10000.1 INSERT INTO #T (T1) SELECT 100000.1 INSERT INTO #T (T1) SELECT 1000000.1 INSERT INTO #T (T1) SELECT 10000000.1 INSERT INTO #T (T1) SELECT 100000000.1 INSERT INTO #T (T1) SELECT 1000000000.1 INSERT INTO #T (T1) SELECT 10000000000.1 INSERT INTO #T (T1) SELECT 100000000000.1 INSERT INTO #T (T1) SELECT 1000000000000.1
SELECT T1 FROM #T
SELECT CONVERT(NUMERIC(36,18),T1) FROM #T




Grasshopper
Group: General Forum Members
Last Login: Saturday, March 7, 2015 6:33 AM
Points: 13,
Visits: 14


interesting indeed! thanks for the little piece of code!
SELECT T1 FROM #T returns "1E06" and "1E05" for the first two lines (called from the SSMS)
Michael




SSCAddicted
Group: General Forum Members
Last Login: Wednesday, January 16, 2013 4:23 PM
Points: 415,
Visits: 2,333


I was actually expecting to also see 1E+05, etc for the positive side of the exponent but nope, just straight digits! So I guess the rule is whatever the programmers felt like at the time!




Grasshopper
Group: General Forum Members
Last Login: Saturday, March 7, 2015 6:33 AM
Points: 13,
Visits: 14




