I have two fields, both have the size set to double in the table properties. When I subtract one field from the other some of the results are displayed as scientific notation when I click in the cell and others just show regular standard format to decimal places.
The data in both fields was updated with Round([Field01],2) and Round([Filed2],2) so the numbers in the fields should not be any longer than 2 decimal places.
Here's an example:
Field1 = 7.01
Field2 = 7.00
But when I subtract Field1 from Field2 the access display shows 0.01 but when I click on the result it displays, -9.99999999999979E-03. So of course, when I try to filter on all results that have 0.01 the query comes back empty because it thinks the result is -9.99999999999979E-03.
Even stranger is if Field1 = 1.02 and Field2 = 1.00, the result is 0.02 and when I click on the result the display still shows 0.02 and I can filter on all results that equal 0.02.
Why would MS Access treat numbers in the same query differently? Why is it displaying in Scientific Notation and not filtering?
Thanks for any support.
Take this simple code in Access (or even Excel) and run it!
Public Sub TestAdd()
Dim MyNumber As Single
Dim I As Integer
For I = 1 To 10
MyNumber = MyNumber + 1.01
Debug.Print MyNumber
Next I
End Sub
Here is the output of the above:
1.01
2.02
3.03
4.04
5.05
6.06
7.070001
8.080001
9.090001
10.1
You can see that after just 7 additions rounding is occurring!
Note how after JUST 7 simple little additions Access is now spitting out wrong numbers and has rounding errors!
More amazing? The above code runs the SAME in Excel!
Ok, I am sure I have your attention now!
If I recall, the FIRST day and first class in computing science? Computers don't store exact numbers when using floating point numbers.
So, then how is it possible that the WHOLE business community using Excel, or Access, or in fact your desktop calculator not come crashing down?
You mean Access cannot add up 7 simple little numbers without having errors?
How can I even do payroll then?
The basic concept and ALL you need to know here is that computers store real (floating) numbers only as approximate.
And integer values are stored exact.
so, there are several approaches here, and in fact if you writing ANY business software that needs to work with money values? And not suffer rounding errors?
Then you better off to choose what we called some kind of "scaled" integer. Behind the scenes, the computer does NOT use floating numbers, but uses a integer value, and the also has a "decimal" position.
In fact, in a lot of older business BASIC languages, or others? We often had to do the scaling on our own. (so, we would choose a large integer format). In fact, this "scaling" feature still exists in Access!!! (and you see it in the format options).
So, two choices here. If you don't want "tiny" rounding errors, then use "currency" data type. This may, or may not be sufficient for you, since it only allows a max of 4 decimal places. But in most cases, it should suffice. And if you need "more" decimal places, then you can multiply the values by 1000, and then divide by 1000 when done the calculations.
however, try changing the column type to currency and that should work. (this type of data is how your desktop calculator also works - and thus you not see funny rounding errors as a result (in most cases).
but, the FIRST rule of the day? First computer course?
Computers do not store exact numbers for floating point numbers - they are approximations, and are subject to rounding errors. Now, if you really are using double for the table, then I don't think these rounding errors should show up - since you have "so many decimal places" available.
But, I would try using currency data type - it is a scaled integer, or so called packed decimal.
You can ALSO choose to use a packed decimal in Access, and it supports out to 28 digits, and you can set the "scale" (the decimal point location). However, since you can't declare a decimal type in VBA, then I would suggest that in the table (and in VBA code, use currency data types).
If you need more then 4 decimal points, then consider scaling the currency in your code, or perhaps at that point, you consider using a packed decimal type in the table, but values in VBA will have to use the "variant" type, and they will correctly take on the data column setting if used in code and assigned a value from the table(s) in question.
Needless to say, the first day you start dealing with computers, and that first day ANYTHING beyond being a "end user"? Well, this is your first lesson of the day!
"The data in both fields was updated with Round([Field01],2) and Round([Filed2],2) so the numbers in the fields should not be any longer than 2 decimal places." instead of rounding up(which i think is the reason for the scientific notation) you can use number field as data type , then under field size choose double, then under decimal places choose 2.
Related
For storing monetary values in MS Access I have 3 options:
Number Double
Number Decimal
Currency
Should I use the last? Or Decimal?
I wonder if this and this applies to Access?
You don’t want to use double, since Excel or Access when using such floating numbers will cause all kinds of rounding errors.
This code demonstrates this issue rather well:
Public Sub TestAdd()
Dim MyNumber As Single
Dim I As Integer
For I = 1 To 10
MyNumber = MyNumber + 1.01
Debug.Print MyNumber
Next I
End Sub
Here is the output of the above:
1.01
2.02
3.03
4.04
5.05
6.06
7.070001
8.080001
9.090001
10.1
You can see that after just 7 addition..already rounding is occurring.
One of the first lessons in computing science is that computers do NOT accurately store floating point numbers (they are only approximate). And thus one REALLY needs to avoid using real numbers when working on financial applications that involve money. Note that the above code runs the SAME even in Excel.
The lesson here is that you thus when using applications that involve money, you need to use integer values to avoid rounding. Currency is such a data type (it is an integer value scaled to include decimal places).
I have a article here that thus explains how to handle numbers that don't cause rounding errors in Access:
http://www.kallal.ca/Articles/rounding/Rounding.html
The short story and rule is simply use currency data types, since floating numbers will cause you many problems.
I have a timesheet application where people put eg. 3.5 hours worked in a day.
Sometimes someone might put 1.25 I guess.
I stored as float but am now having issues when I retrieve data... Should I have used decimal to 2 or 3 points?.
There are a few ways to tackle this.
If you want to have uniformity in the entries, I'd suggest using a "Fixed-Point Type" value (see more info here). This would mean that 3.5 hours should always be saved as 3.50.
The other option is to convert all your values to integer values (see more info here), and in your application layer, convert the values back to "readable" format. For example, you would store 1.25 hours as 125, and in your application layer, divide by 100, therefore getting 1.25. This method is more useful for currency management/calculation applications where a specific level of precision is necessary.
Floats allow for floating decimal point precision, so there is no restriction on uniformity of precision for decimal values...
For your purposes, I'd recommend fixed-point type unless there's complexity that you didn't mention.
Hope that helps.
With Microsoft Access 2010, I have two Single fields:
A = 1.1
B = 2.1
I create a query where I have defined C=A*B
Microsoft Access says that C = 2.30999994277954
but, in reality, C =2.31
How can I get the right result (2.31)?
Slightly off results from operations performed on decimal values can happen if your numeric field size is single or double rather than decimal. Single and double (or floating point) numbers are very close approximations of the "true" numbers, but should not be relied upon if accuracy in operations is required. A related stackoverflow question has more information about this issue: Access comparing floating-point numbers "incorrectly"
If it's possible to modify the underlying table's design, you should change the field size property for the "A" and "B" fields from single to decimal. After changing the field size BUT BEFORE saving the table, you will also need to adjust the Scale property for "A" and "B" from 0 to whatever number of places to the right of the decimal point you might require. You will likely still have a notice about losing data, but if you adjust the field properties correctly before saving the table, this shouldn't be a problem. You should probably make a copy of the table before doing this so that you can verify that there was no data loss. After saving your table and verifying the changes did not result in data loss, your query should represent A * B accurately.
I have an application in which users are typing measured amounts. I would like to respect the precision they are entering when storing the values in MySQL, i.e. if they type 0.050 I don't want that to become 0.05 since that is loosing information on how exact the measurement was done. Is there a way other than storing the value as a string?
0.050 is equal to 0.05 . If you want 3 digits after comma, you have to implement this feature in application.
As per my knowledge for handling precision point we are using FLOAT, DOUBLE or DECIMAL data types. In your case if you are not using any function like SUM(),AVG(),etc then you can use VARCHAR.
Add always a "control" digit, lets say "1", save to database, then get data from database and always trim ONE time the "control" digit "1" from what you've got.
example:
user inputs 0,000050
save as 0,0000501
get the 0,0000501
trim the last "1" (only the last one be carefull)
k.i.s.s. people :D
edit: proper solution of course, add a column to store precision and right-pad zeroes if needed
I am currently importing a data set that includes currency values into an Access database. Although I've read that I should be using the decimal data type for currency, can I not use double to cut down on the file size if the values are rounded to the nearest dollar?
As far as I can tell, the issue with using double for currency is due to rounding, but I won't be doing calculations on the data directly. Any calculations will be done by the application/user.
Similarly, as the data is fixed-length, some of the decimal values are represented by whole numbers. For example, some fields may contain a value of 12345, but the actual value is 12.345. This requires that I import the data and then update the values; dividing by 1000 in the example above.
Will using double in this fashion cause rounding errors as well?
Yes, divisions can and will introduce rounding errors.
You want to use "currency" for ANY kind of business software. In fact if you don't have a currency data type then you use SCALED integers (you scale the results). You thus store
$123.52
As
1235200
(Assuming 4 decimal places)
The reason of course is "real" numbers in computers are only a representation and are only approximate – they are subject to rounding.
This is SIMPLE code:
Public Sub TestAdd()
Dim MyNumber As Single
Dim i As Integer
For i = 1 To 10
MyNumber = MyNumber + 1.01
Debug.Print MyNumber
Next i
End Sub
Here is the actual output of the above:
1.01
2.02
3.03
4.04
5.05
6.06
7.070001
8.080001
9.090001
10.1
Imagine the above – after just 7 SIMPLE and SILLY additions we already getting WRONG answers. And VBA even in Excel will do the SAME. So as noted, we are using 0.01, but it only approximate! (so while we assume this value is 1/100th, it only approximate when using the "real" format in computers.
So computers cannot and do NOT store real numbers to an exact precision. You get rounding errors as a result.
For payroll or anything to do with business applications and money you have to use scaled integers else your tables and accounting and even reports will NOT add up and you experience rounding errors.
I cannot think of any benefits in terms of storage space unless you storing many millions of rows of data. MUCH worse is if you export this data to some other system, then exporting "real" numbers can introduce all kinds of artifacts and even exponents when exporting - use currency - you be safe in what you see and have.