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)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.
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.
Kind regards, Eelco