I have a MS Access 2010 database with a products table. The price column is a single datatype with format set to Fixed(2). There are certain values that are not being represented correctly, and I've no idea why. For example, one price is shown in the table as 1.52. However, if I export to Excel, or view it in a form with the Currency format, I see that Access has really stored 1.51999998092651. No matter what I do, I can't seem to change the value to represent the 0.20 correctly.
I know that computers store reals as approximations, but this seems rather ridiculous. Any ideas what's going on here and how I can fix it?
Replace 'Single' datatype to 'Currency', or at least to 'Double'.
Floating point numbers in common do not have accurate binary representation. Certainly 'Double' type will have less mistakes. So you need to use fixed point numbers, named 'Currency' in ms access. But they have limited precession 15 digits before and 4 digits after point.
P.S. You have to change type, not format.
Related
Hi My Fellow Access user.
I am using Access to do reconciliation, by link two Excel sheets. the number are two decimal.
Linked Table view
However, when i was trying to run subtraction between two numbers both 2 decimals, it return results like this:
Appreciate if anyone know how this could happen, and what steps I need to take to fix it?
Thanks
Tian
Don't use the linked Excel data directly.
Create simple select queries where you can convert and trim your data. Like:
Select SomeField, Description, CCur([TotalAmount]) As Total
From YourLinkedExcelTable
When dealing with amounts, always use Currency as data type.
Now, calculate your Diff using the query.
For a linked Excel sheet, the column type is probably Double, a 64-bit floating point number. This problem you experience is probably due to an inherent limitation of floating point numbers and is not unique to Excel or Access.
This Stack Overflow question asks essentially the same thing: Why does this subtraction not equal zero?
Excel is no exception, only that the default formatting might not show the necessary precision to reveal the behavior. Selecting scientific format or increasing the number of displayed decimal places will reveal the same behavior.
Consider the following:
For monetary amounts, convert values to Currency using the CCur() function. Currency is a fixed-decimal value, but be aware it only has 4 digits to the right of the decimal. (Updated to reflect advice from Gustav)
Convert values to fixed-point Decimal type using CDec() function before performing the math. There is no native VBA Decimal type, so these are variants containing Decimal values. But upon conversion back to floating-point, it is still possible to experience extra digits.
Round the results using the Round() function, but again this is not guaranteed to eliminate floating-point limitations.
Choose an explicit format for displaying the numbers.
i have column which is in int and float format.
ex:10000
but i need to display this value in UI as money format with comma separation. i have written below code to convert it.
PARSENAME(CONVERT(VARCHAR,CAST(amount) AS MONEY),1),2)
EX: amount=10000
Result of the above query is 10,000
since the above conversion uses PARSENAME, CONVERT, CAST etc., i feel that some performance over head will be there, but i am not sure.
Is there any best way to do above operation? or this is good.
This question has been asked many times before, but I've found conflicting opinions on the topic so I thought I would bring it up again in hopes of a more unified conclusion.
I would like to store a currency value in my database. Let's assume all entries are the same type of currency (USD for example) and that both positive and negative values are allowed.
My initial thought would be to store the value as a signed integer in terms of the smallest unit of the associated currency. For example, if I want to store the value $1.25, I would insert 125 into the database, since the smallest unit of USD is $0.01. The nice thing about this method is that MySQL will automatically round to the nearest integer. For example, if the dollar value is $1.259, I could insert 125.9, which would automatically be rounded and stored as 126 or $1.26.
So, what do you think? Is this a sound approach or is there a better way?
Financial data can be stored as DECIMAL(p,s) where p is the number of significant digits, and s is the scale (number of places to the right of the decimal point). See The MySQL documentation.
Also from O'Reilly's High Performance MySQL, chapter 3:
"...you should use DECIMAL only when you need exact results for
fractional numbers--for example, when storing financial data."
From O'Reilly's Learning MySQL:
DECIMAL is, "...A commonly used numeric type. Stores a fixed-point
number such as a salary or distance..."
And MySQL Pocket Reference:
DECIMAL "...Stores floating-point numbers where precision is
critical, such as for monetary values."
There is nothing wrong with the approach you describe. There is no right or wrong when it comes to this question.
You have to keep in mind that to display a $ value to the user, you would need to always do a division operation or some kind of formatting.
Will it be easier to debug your formulas/calculations if everything was in cents or dollars? Will you be displaying the values in cents or dollars? etc.
Keep it simple, but either way you'll have to use a decimal.
I am trying to figure out how to store 1/3, or any fraction which results in an infinitely repeating decimal value in MySQL. I cannot just use 3.333333 because it obviously does not total to 100. I have been reading about the float datatype but i'm not sure if this will work. Any help would be appreciated.
Thank you
You could potentially represent all rational numbers (including integers) as "numerator" and "denominator". So in your table you'd have a numerator and denominator columns, and your app would have logic to store numbers using that form.
You would still be unable to store irrational numbers precisely with this technique (i.e. if you want to store Pi, you'd need a fractional approximation anyway).
See here for what rational numbers are, so you can understand the limitations of this technique.
http://en.wikipedia.org/wiki/Rational_number
Store the numerator and the denominator in separate columns. It's really that simple. The real problem comes later when you want to add up all the fractions. Some languages have built-in facilities to do so, but I don't think MySQL does.
We want to store product prices and weight (kg/pound) in MySQL. Can somebody tell me what's the best way to do this?
double/decimal/... ?
We need to be able to display both USD and EURos.
I don't know if it helps, but we use the Zend framework to build our application.
Have you looked at the Zend_Currency family of functions?
This component works with all available locales and therefore knows about more than 100 different localized currencies. This includes informations like currency names, abbreviations, money signs and much more.
Zend_Currency has the advantage that already defined currency representations can be reused. You could also have 2 different representations for the same currency.
Zend_Currency allows you also to calculate with currency values. Therefore, it provides you an interface to exchange services.
If you like that part of the Zend Framework, I guess a lot of decisions will "sort themselves out" based on what they use to work with the values.
for currency use decimal
from http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html :
The DECIMAL and NUMERIC data types are used to store exact numeric data values. In MySQL, NUMERIC is implemented as DECIMAL. These types are used to store values for which it is important to preserve exact precision, for example with monetary data.
We always use decimal and add a currency_id field to denote currency.
You can create a currency table with id, and name, and sign and join it on queries for price.