I need to do some very precise reporting in SQL Server Reporting Services. I'm actually attempting to show 13 decimal places. The odd part is even when I format the field C13, Reporting Services seems to round after an arbitrary number of total digits rather than anything to do with the format string.
For example if I have:
1000.01234567890123
What I end up with is:
1000.0123456789000
If on the other hand I have:
10.01234567890123
What I end up with is:
10.01234567890100
So it appears that I only end up with 15 actual digits from my source number. Has anyone seen this before, or know how to resolve it?
It sounds to me like you are using the Float datatype. Instead, I would suggest you use the decimal data type instead. You'll probably want to use something like Decimal(20, 14). You'll still need to be very careful about the math you perform because SQL Server will modify the resulting data type when you perform math on decimals.
Actually, I found the problem was Microsoft's Double.ToString() method. I had to use a "G13" as a formatting string to get all of the decimal places. Go figure.
Related
I'm doing a report from our database regarding some amount
It shows like this in the report from the front end
however in the backend it's like this
It seems that the system adds a decimal point before the last two digits of the entries I've check the other ones and this seems to be the case
My question is, is there a function that I can use to append a decimal point before the last two digits whenever I generate the report in postgres?or is there another way to achieve the same result?
So I can provide a backend report that shows the same as the front end
Assuming the amount values are actually in cents, you should be able to just divide by 100:
SELECT expense_date, CAST(amount / 100.0 AS money) AS money
FROM yourTable;
Also, you may wish to handle this formatting issues in your presentation layer rather than directly on Postgres.
I have a table in which one of field is Real data type. I need to show the values in decimal format like #.###. So i'm converting the real values to decimal. But when i convert for some values it is not generating actual value. For eg:- 20.05 is the actual value. multiple it by 100 and then it to decimal(9,4) it will return like 2004.9999.
select cast(cast(20.05 as real)*100.00 as decimal(9,4))
Why this is returning like this ?
Real or Float are not precise...
Even if you see the value as "20.05", even if you type it in like this, there will be tiny differences.
Your value 2004.9999 (or similar something like 2005.00001) is due to the internal representation of this type.
If you do the conversion to decimal first, it should work as expected:
select cast(cast(20.05 as real) as decimal(9,4))*100.00
But you should really think about, where and why you use floating point numbers...
UPDATE: Format-function
With SQL-Server 2012+ you might use FORMAT() function:
SELECT FORMAT(CAST(20.05 AS REAL)*100,'###.0.000')
This will allow you, to sepcify the format, and you will get text back.
This is fine for presentation output (lists, reports), but not so fine, if you want to continue with some kinds of calculations.
I need to store the following double value in SQL Server:
double x = 52.22105994970536;
What SQL Server datatype should I use to store values of this type. Perhaps decimal or float?
I am not sure if this is relevant but I need to store these values with a . not a , to separate the fractional portion of the values. Is there a setting in SQL Server that I should be aware of to ensure this happens?
I am not sure if this is relevant but I need to store these values with a . not a , to
separate the fractional portion of the values. Is there a setting in
SQL Server that I should be aware of to ensure this happens?
No, it is totally enough to learn programming to the point you realize that this is not a question at all - decimals are stored as decimals. "." or "," are part of the visual conversion (the "ToString" call, so to say) to print the value and have nothing to do with the value.
If you want to store a double, you want to store a double. Point. If you want to make sure your program presents it with a ".", then PROGRAM THE UI PROPERLY, but do not bother SQL Server internal storage with it. Normally they are shown in the locale - which is smarter than hardcoding in most cases. SO, maybvbe you force-change the UI locale? Or hardcode the conversion to apply every time you print out a value.
What SQL Server datatype should I use to store values of this type. Perhaps decimal or
float?
http://msdn.microsoft.com/en-us/library/ms187752.aspx
explains the data types of sql server.
Choose one that fits your requiremnents. Likely a float version with a given precision. Now, if you ar afraid because those are named as "approximate numeric" note that a double IS an approximate numeric, also in C# (or any other front end language you use - you do not tell us).
Default recommended mappings are at http://msdn.microsoft.com/en-us/library/ms131092.aspx and would point towards a "float".
As Damien_The_Unbeliever stated formatting is (well should be irrelevant) formatting is something you do for display, reporting etc.
As for whether to use floating point or fixed point (decimal), decimal solves a lot of issues IF the language you are using to access it has a decimal type. If you are manipulating the numbers as doubles then using decimal on the back end won't give you that much, as you will still be manually coping with the inherent inaccuracies of floating point representation.
We have SQL Server 2000 database with money data type columns and we have strange problem with numbers within money columns in which we store numbers with 2 decimal places. For o long time everything was OK. But now I see that in some rows where was number 47.22 is now number 47.2178. When i select CAST(COLUMN as CHAR) result is 47.22 but when i retrieve value from ADO recordset i have result 47.2178. I browse all application if there is any place where it can write number with 4 decimal places and find nothing(and in application history log there are records that application writes 47.22 to database). Can it be some SQL Server problem?
edit:application is written in VB6
Are you actually using the money data type or are you using a floating point type?
What happens when you use enterprise manager to select from that table? Does everything look ok?
My guess is that you are converting the data to a floating point type somewhere along the way. Probably in the ADO code.
UPDATE
Per MS: When casting money to a string type, the machine's locale comes into play. Which is why it is rounded to 2 decimal places.
You have three options.
First cast the money type to an equivalent decimal then cast that result to a char
Change the machines Regional Settings to default to the format you want.
Don't use the money data type to begin with, just use a decimal.
Don't use Enterprise Manager to draw any conclusions on what is really stored in your tables. EM has sometimes its own opinion on how to interpret data.
Looking at your CAST(....to CHAR) the reason is explained in the documentation (look for CAST & CONVERT)...
The following table shows the values
for style that can be used for
converting money or smallmoney to
character data.
Value Output
0 (default) No commas
every three digits to the left of the
decimal point, and two digits to the
right of the decimal point; for
example, 4235.98.
1 Commas every
three digits to the left of the
decimal point, and two digits to the
right of the decimal point; for
example, 3,510.92.
2 No commas
every three digits to the left of the
decimal point, and four digits to the
right of the decimal point; for
example, 4235.9819.
EDIT: Finally figured out how to use the BlockQuote feature. :-)
I am working on a legacy ASP application. I am attempting to insert a value (40.33) into a field in SQL Server 2000 that happens to be a float type. Every place I can see (via some logging) in the application is sending 40.33 to the Stored Procedure. When I run SQL Profiler against the database while the call is happening, the value that I see in the trace is 4.033000183105469e+001
Where is all the extra garbage coming from (the 183105469)?
Why is it that when I pass in 40, or 40.25 there is nothing extra?
Is this just one of the weird side effects of using float? When I am writing something I normally use money or decimal or something else, so not that familiar with the float datatype.
Yes, this is a weird, although well-known, side effect of using FLOAT.
In Microsoft SQL Server, you should use exact numeric datatypes such as NUMERIC, DECIMAL, MONEY or SMALLMONEY if you need exact numerics with scale.
Do not use FLOAT.
I think this is probably just a precision issue - the 0.33 part of the number can't be represented exactly in binary - this is probably the closest that you can get to.
The problem is that floats are not 100% accurate. If you need your numbers to be exact (especially when dealing with monetary values)... you should use a Decimal type.