Double vs. Decimal Data Type - Access 2010

[WriterCat]

I have an account number field with a number of 17 digit values. Our default for that field in our Access tables has been a double data type. That worked fine until we started getting the large account numbers.

Many, such as 62078190357102307, behave fine. That account number imports as expected.

However, if the account number ends in 199, 299, etc., such as 10024912715100199, it comes into the table as 10024912715100200 if the field format is double.

In the source DB2 table, the field is Decimal 20. If I format the Access table field as Decimal 20, all is well.

My problem is that we have the account number field everywhere in multiple databases, tables, queries and reports. It is a key field for us. Changing it everywhere would be a challenge.

Can someone enlighten me as to why the fields appear to round if they end in 99. Is there anything I can do to prevent that, short of reformatting all of my account number fields as decimals?

Thanks!

Nancy

[MarkLiquorman]

Don't take this as gospel, but as I understand it, a floating point number stores the exponential of the number you entered, so it is really an approximation of the actual number (although a very good one). I think a double has an accuracy of 16 characters, so you are past it.

I don't think there is a way to get around this other than to restrict your account numbers to something a double can handle. You will have to convert them to either a decimal or a text string.

[enjoy]

Hey Nancy,

Mark is spot on.
Access uses variables stored in the Double Precision floating point format.

From Wikipedia (https://en.wikipedia.org/wiki/Double_precision):
This is a binary format that occupies 64 bits (8 bytes) and its significand has a precision of 53 bits (about 16 decimal digits).

This is the information in figures related to those 53 bits for the precision:
Between 2⁵²=4,503,599,627,370,496 and 2⁵³=9,007,199,254,740,992 the representable numbers are exactly the integers. For the next range, from 2⁵³ to 2⁵⁴, everything is multiplied by 2, so the representable numbers are the even ones, etc.

This means that if a number is stored higher than 2⁵³, you can face a rounding problem to the next even number.
Your failing odd account numbers are in the range of 2⁵³ and 2⁵⁴:
09,007,199,254,740,992 (2⁵³, 0 inserted in front to make this line up with the next line)

10,024,912,715,100,199 (from your example)

Your successful conversion example (62,078,190,357,102,307) is a value higher than 2⁵⁴ (= 2 x 2⁵³) so they might be representable, but also they might not.

Unfortunately, this means that the Access database's design doesn't match the original DB2 data definition, which is a fixed 20-digit decimal representation.

I am sorry, but the only way to solve it is to make these fields match the original data type in the DB2 table exactly.

Kind regards, Eelco

[WriterCat]

Thank you both for your explanations. I can work around this knowing what is happening - I'm thankful that it wasn't something I messed up or imagined.

Nancy

[Cronk]

This way you can have the account code much longer if you want.

[johnhutchison]

Why not use a text field for the account number?

I agree that a text field is the right solution.
But Nancy has said: "My problem is that we have the account number field everywhere in multiple databases, tables, queries and reports. It is a key field for us. Changing it everywhere would be a challenge."