Rounding of static value is different from rounding DB field value in SAP B1 crystal report 2011
I have 609,437.50 from Database when I go to Field Format and then round field I get 609,437
I have 609,437.50 in formula as static value when I round I get 609,438 which is correct same as excel
How can I round Database field and get value like 609,438 while I have 609,437.50?
Please anyone can help me
You likely have database value different from xxx.50.
What data type is your value in database - some float or decimal or money?
If float, then you have to convert it to decimal first - float values are inexact and rounding may behave strangely.
If decimal or money, then you may have more decimal places filled (like xxx.499), which rounds down again. You need either accept your results or round to two decimals first; this can be visually better, but is wrong mathematically.
Related
Round() is not working properly in crystal reports. I have value 99.52865, I'm rounding the value to 4 decimal places by using Round function. The Function Displaying Value after rounding is 99.5286 but it has to round to 99.5287. For Some values it is rounding properly like 0.40465 to 0.4047. Facing issue for some values only.
An answer to a question about a good schema for stock data recommended this schema:
Symbol - char 6
Date - date
Time - time
Open - decimal 18, 4
High - decimal 18, 4
Low - decimal 18, 4
Close - decimal 18, 4
Volume - int
In addition, Postgres documentation says:
"If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead (of floating point types)."
I'm fairly new at SQL, and I hope this is not a really naive question. I'm wondering about the necessity of using the numeric datatype (especially 18,4) - it seems like overkill to me. And "exact" is not really something I'd specify, if exact means correct out to 12 decimal places.
I'm thinking of using real 10,2 for the monetary columns. Here's my rationale.
A typical calculation might compare a stock price (2 decimal places) to a moving average (that could have many decimal places), to determine which is larger. My understanding is that the displayed value of the average (and any calculated results) would be rounded to 2 decimal places, but that calculations would be performed using the higher precision of the stored internal number.
So such a calculation would be accurate to at least 2 decimal places, which is really all I need, I think.
Am I way off base here, and is it possible to get an incorrect answer to the above comparison by using the real 10,2 datatype?
I'd also welcome any other comments, pro or con, about using the numeric datatype.
Thanks in advance.
Floating point variables are vulnerable to floating point errors. Therefore, if accuracy is important (anytime money is involved) it's always recommended to use a numeric type.
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
Floating point inaccuracy examples
Let's start with the schema above, and look how 18,4 would look like in floating point numbers:
select '12345678901234.5678'::float4;
float4
-------------
1.23457e+13
(1 row)
select '12345678901234.5678'::double precision;
float8
------------------
12345678901234.6
(1 row)
Therefore 14 numbers (before the decimal point) will always round your number, and you store rounded (and therefore wrong) values.
Also your assumption about rounding to two decimal places - where is that assumption coming from?
select '1.2345678'::float4;
float4
---------
1.23457
(1 row)
Therefore, so far you presented a number of assumptions, and shortcuts, without showing why you want to use floating point numbers instead of numeric. What is your compelling reason? Just save some bytes?
My next question is: if your application expands, and does more than just "avg" calculations - do you need to chance the data type to numeric again?
I have a crystal report where a numeric field needs to be a fixed length with a decimal and needs to not round up or down. I changed it to a text field but now when I run the report and I forget to change the options in crystal for a number field to show ####.## it rounds to nearest dollar amount and drops the cents. How can I fix it so I won't have to remember to change the options?
An example may be helpful -
If the field is numeric, or decimal, you can right click the field, select "format field", click Customize, Number, and select the rounding and decimal logic.
if you don't have enough decimal places allowed (say, zero decimals) then make sure the rounding is not set to "1" - that would cause the number to round up. if the rounding is less than or equal to the decimal places, it should just 'truncate' and not round.
I've a small number in a PostgreSQL table:
test=# CREATE TABLE test (r real);
CREATE TABLE
test=# INSERT INTO test VALUES (0.00000000000000000000000000000000000000000009);
INSERT 0 1
When I run the following query it returns the number as 8.96831e-44:
test=# SELECT * FROM test;
r
-------------
8.96831e-44
(1 row)
How can I show the value in psql in its decimal form (0.00000000000000000000000000000000000000000009) instead of the scientific notation? I'd be happy with 0.0000000000000000000000000000000000000000000896831 too. Unfortunately I can't change the table and I don't really care about loss of precision.
(I've played with to_char for a while with no success.)
Real in Postgres is a floating point datatype, stored on 4 bytes, that is 32 bits.
Your value,
0.00000000000000000000000000000000000000000009
Can not be precisely represented in a 32bit IEEE754 floating point number. You can check the exact values in this calculator
You cold try and use double precision (64bits) to store it, according to the calculator, that seems to be an exact representation. NOT TRUE Patricia showed that it was just the calculator rounding the value, even though explicitly asking it not to... Double would mean a bit more precision, but still no exact value, as this number is not representable using finite number of binary digits. (Thanks, Patricia, a lesson learnt (again): don't believe what you see on the Intertubez)
Under normal circumstances, you should use a NUMERIC(precision, scale) format, that would store the number precisely to get back the correct value.
However, your value to store seems to have a scale larger than postgres allows (which seems to be 30) for exact decimal represenations. If you don't want to do calculations, just store them (which would not be a very common situation, I admit), you could try storing them as strings... (but this is ugly...)
EDIT
This to_char problem seems to be a known bug...
Quote:
My immediate reaction to that is that float8 values don't have 57 digits
of precision. If you are expecting that format string to do something
useful you should be applying it to a numeric column not a double
precision one.
It's possible that we can kluge things to make this particular case work
like you are expecting, but there are always going to be similar-looking
cases that can't work because the precision just isn't there.
In a quick look at the code, the reason you just get "0." is that it's
rounding off after 15 digits to ensure it doesn't print garbage. Maybe
it could be a bit smarter for cases where the value is very much smaller
than 1, but it wouldn't be a simple change.
(from here)
However, I find this not defendable. IMHO a double (IEEE754 64bit floating point to be exact) will always have ~15 significant decimal digits, if the value fits into the type...
Recommended reading:
What Every Computer Scientist Should Know About Floating-Point Arithmetic
Postgres numeric types
BUG #6217: to_char() gives incorrect output for very small float values
Friends,
This is the formula in the crystal reports 9.
cdbl({nrconsolidated.collamt})/100000.000
nrconsolidated table is having 9 records.
in that one record's collamt value is 154250.
but in the crystal reports output its showing as 1.543 instead of 1.542.
i want only 3 decimal points.i dont know where the mistake is coming from?
in the crystal reports, i clicked on that collamt field and checked the data by seeing the browseData option...its showing as 154250.
how can i solve this issue? its showing the correct value in 4 decimal points but i want only 3 decimal points.
thanks
The below code will truncate the result after the calculation has been performed, and output it to 3 decimal places. This works for Crystal Syntax and should for Basic as well - I believe it is common amongst both.
truncate(cdbl({nrconsolidated.collamt})/100000.000,3)
On the field set the decimals 1.000 and rounding 0.001 will display what you want.