Results 1 to 6 of 6
  1. #1
    2 Star Lounger
    Join Date
    Oct 2004
    Location
    Minnesota, USA
    Posts
    144
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Double vs. Decimal Data Type - Access 2010

    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

  2. Get our unique weekly Newsletter with tips and techniques, how to's and critical updates on Windows 7, Windows 8, Windows XP, Firefox, Internet Explorer, Google, etc. Join our 480,000 subscribers!

    Excel 2013: The Missing Manual

    + Get this BONUS — free!

    Get the most of Excel! Learn about new features, basics of creating a new spreadsheet and using the infamous Ribbon in the first chapter of Excel 2013: The Missing Manual - Subscribe and download Chapter 1 for free!

  3. #2
    Gold Lounger
    Join Date
    Jun 2001
    Location
    Crystal Beach, FL, Florida, USA
    Posts
    3,326
    Thanks
    1
    Thanked 12 Times in 12 Posts
    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.
    Mark Liquorman
    See my website for Tips & Downloads and for my Liquorman Utilities.

  4. #3
    Lounger
    Join Date
    Dec 2009
    Location
    Leiden, Netherlands
    Posts
    29
    Thanks
    2
    Thanked 4 Times in 2 Posts
    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 252=4,503,599,627,370,496 and 253=9,007,199,254,740,992 the representable numbers are exactly the integers. For the next range, from 253 to 254, everything is multiplied by 2, so the representable numbers are the even ones, etc.

    This means that if a number is stored higher than 253, you can face a rounding problem to the next even number.
    Your failing odd account numbers are in the range of 253 and 254:
    09,007,199,254,740,992 (253, 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 254 (= 2 x 253) 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
    Last edited by enjoy; 2012-03-28 at 05:40. Reason: formatting errors
    - Eelco

    *** Puzzle me! ***

  5. #4
    2 Star Lounger
    Join Date
    Oct 2004
    Location
    Minnesota, USA
    Posts
    144
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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

  6. #5
    Lounger
    Join Date
    Feb 2011
    Posts
    43
    Thanks
    0
    Thanked 6 Times in 6 Posts

    Why not use a text field for the account number?

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

  7. #6
    Super Moderator
    Join Date
    Jun 2002
    Location
    Mt Macedon, Victoria, Australia
    Posts
    3,993
    Thanks
    1
    Thanked 45 Times in 44 Posts
    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."
    Regards
    John



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •