Access Bugs

  • Thread starter Thread starter B
  • Start date Start date
B said:
Where do you submit bugs for Access 2000 and Access 2003?

Bugs in A2000 won't be fixed any more. Only security patches. This
is part of Microsoft's life cycle methodology/whatever it's called.
A2003 some hot fixes are still coming out occasionally.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I believe Access 2003 is storing number data types wrong when storing them as
a Single with decimal places. When Access stores 0.1 it adds extra data to
the end resulting in 0.100000001490116, when this number is compared to 0.1
of another data type (field size Decimal) the two numbers are not equal.
 
I believe Access 2003 is storing number data types wrong when storing them as
a Single with decimal places. When Access stores 0.1 it adds extra data to
the end resulting in 0.100000001490116, when this number is compared to 0.1
of another data type (field size Decimal) the two numbers are not equal.

That's not a bug. That's the nature of floating point numbers - they're
approximations. The same conflict occurs in Fortran or Excel or C or any other
language.

A floating point (single) number is stored as an 8 bit exponent and 24 bit
mantissa; the mantissa is a binary fraction between 0.5 and 0.99999999999999
or so, and the exponent is a power of two. Multiplying the mantissa by two to
the power of the exponent gives you a number in the range defined in the Help
file:

A single-precision floating-point value with a range of – 3.402823E38 to –
1.401298E-45 for negative values, 1.401298E-45 to 3.402823E38 for positive
values, and 0.

Any number in this range is restricted to 23 bits of precision, approximately
7 decimal places. Just as the decimal expansion of 1/7 is not exact, so the
binary expansion of 0.1 is an infinitely repeating binary fraction - and
truncating it to 24 bits means that it cannot be represented exactly.
 
Well that explains it but surely this is a trap.

If I can’t get 0.1 Single to equal 0.1 Decimal then why are we allowed to
compare these data types? Also when we start using arithmetic on these
single values the answers are not what is expected (0.1 + 0.1 =
0.200000002980232). I don’t mind how Access stores the data but I do care
about the results, if this isn’t a bug then it is a serious limitation.
 
Well that explains it but surely this is a trap.

If I can’t get 0.1 Single to equal 0.1 Decimal then why are we allowed to
compare these data types? Also when we start using arithmetic on these
single values the answers are not what is expected (0.1 + 0.1 =
0.200000002980232). I don’t mind how Access stores the data but I do care
about the results, if this isn’t a bug then it is a serious limitation.

It's annoying for sure. You need to take the nature of such numbers into
account, and use a "fuzz factor" rather than comparing equality. If at all
possible, you should use a consistant datatype. Currency or Decimal numbers
don't have the roundoff error - but don't have the range either. If you need
numbers like 10^25 (or for Double, 10^250), or 10^-20, or variable numbers of
decimals (Currency gives you four places), then you're stuck.

For what it's worth, I learned about the problem (in Fortran II on a
room-filling CDC3600) in 1968. It's not news.
 
Thanks.

John W. Vinson said:
It's annoying for sure. You need to take the nature of such numbers into
account, and use a "fuzz factor" rather than comparing equality. If at all
possible, you should use a consistant datatype. Currency or Decimal numbers
don't have the roundoff error - but don't have the range either. If you need
numbers like 10^25 (or for Double, 10^250), or 10^-20, or variable numbers of
decimals (Currency gives you four places), then you're stuck.

For what it's worth, I learned about the problem (in Fortran II on a
room-filling CDC3600) in 1968. It's not news.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top