I want to persist a sum of double values as Decimal(4,2) in my database and display it to the user. The issue I have is, that the decimal number is stored correctly in my database with two decimal digits. But when querying it from the database in some cases it displays a lot more decimal digits to the user.
In my Entity class I have:
#Column(name="weight_sum", precision=6, scale=2)
private double weightSum;
In my MySQL Database I have a column specified as
Decimal (4,2)
I don't understand where I made the mistake.
Actually you are doing correct things but you need to do some more stuff.
If you have define precision and scale for weightSum of entity class then it will save into db accordingly.
But when you get back data from db and bind to corresponding entity class then it will again take default scale(actual scale following by zero) and precision value.
So whenever you send data to end user you need to set scale as-
weightSum.setScale(2, BigDecimal.ROUND_FLOOR);
In above method 2nd parameter is roundingMode, you should select roundingMode as per your requirement.
I hope it will help you out. Thanks
Related
When I'm fetching data from my access database with pyodbc, it returns false format for float, date, or integers.
For example:
These values
Are returned like this
I've been searching for a long time now, I think it comes from the ODBC Driver used, but realy, I have no clue.
Another example would be a date like "21/01/2021" of type DATE in my MS Access DB, will be returned as a datetime in chinese or korean format YYYY-mm-dd H:m:s.
Floating-point columns (Numeric(Double) and Numeric(Single)) will display all decimal places in the Access UI if the field definitions in the table use the default formatting options
Format: (empty)
Decimal Places: Auto
Changing those settings to
Format: Fixed
Decimal Places: 2
will change the display format in the Access UI but the number itself will still be stored with its full precision. The ODBC driver does not pay attention to those formatting properties, so it returns the values with all available decimal places.
As for Date/Time values, the default format in the Access UI is to display just the date if the time component is exactly midnight. However the Date/Time value is stored with that time component (00:00:00) and again, the ODBC driver returns the complete value. See this answer for a more detailed explanation.
I need to save the avg of a value, that in this case corresponds to the average attendance of a venue, and for this, I created a new field called avg which has this structure: decimal(10,3).
Now if I store a value like this: 2671, the field will contain: 2.671 that's correct, but if I need to store only 800 I'll get: 800.000 that's, of course, is a different number…
So how can I store the correct decimal value? In this case should be only 800, not 800.000.
Also, how can I adjust the bad values stored in the database without repeat all the insert?
Thanks.
The decimal point is irrelevant, you can trim the decimal point using another function.
I have a current db table called scores that has 2 columns user_score and approved_score which are both Integer.
After initial launch we have decided to make things more exact by add a decimal to a score. So instead of getting a 10 you could get a 10.40 or a 10.47 ect. I am just curious on:
Should I change it to a decimal or a float based on us needing 2
decimal points with trailing 0. So: $table-> decimal('user_score', 8,
2)->change();
Will that mess up data in there already? Like will a
score of 123 stay 123? We rank based on score so the higher the
better.
A float would be more appropriate in this case, it doesn't sound like you need a high number of precision points after the decimal place. The data should not be impacted by changing the column type, so long as your values are not currently larger than (8,2).
Also, updating your existing data if you kept the column as an integer would be trivial as all you would need to do is UPDATE column SET column=column*100.
i was trying to create a money related app in which users can choose their currency. Mysql datatype i tried is decimal(19,4). Now the problem is few currencies need three precisions and some need two
Eg:
oman rial needs three precisions. ie 1000 baisa = 1 omani rial. Hence my customers may enter 6.783 omani rial.
Where as my US customers will need only 2 precisions as 100 cents = 1 dollar and they may enter 5.50.
When i insert these two entries to my database using decimal(19,4), it is saved as 6.7830 and 5.5000 respectively.
Now the real pain is when i need to display their entrys as i dont want to display that extra 0 in omani rial entry and that 00 in US dollar. I also tried float but last digit gets rounded off at times.
Is there any mysql data type in which i can save exact entry as it is without any rounding off or extra zeros? If there is no such entry, how can i make it ppssible?
You can use VARCHAR to store exact representations, but I don't recommend that because it takes more bytes to store a number as a string. And any arithmetic you do on the value will convert it to a number anyway.
I recommend you use DECIMAL(19,4), and then format the value in application code, to display it with the appropriate digits. Every programming language has some function like printf() that allows you to control the output formatting, regardless of the value stored.
I'm trying to store price figures in my Access database and am using a Currency field (instead of Decimal) for reasons, including the fact I'm using an old version of Access that are detailed in this thread: Syntax error in PARAMETER clause when passing through parameters as Decimal types using MS Access querydefs.
For consistency between systems I need to store the prices to 6 decimal places. However regardless of the settings I choose in Access, the values I type in are automatically rounded to 4 decimal places.
Here is the field in the table setup to 8 decimal places (I need 6 but was trying more in case):
Here is the just entered, as yet unrounded figure:
And after I press return, the value saves to the table, but rounded to four dps:
Is there any way to get MS Access to store currency datatypes to more than 4 decimal places? Am I doing something wrong?
Many thanks,
Jamie
For anyone that has the same problem as me, I've solved it by using currency parameter types in the querydef and decimal fields in the table:
Decimal data type:
Currency param:
This gets over issues with the decimal param type (detailed here:Syntax error in PARAMETER clause when passing through parameters as Decimal types using MS Access querydefs) and issues with the currency field rounding to 4 dps http://msmvps.com/blogs/access/archive/2009/04/27/the-problems-with-currency-fields.aspx