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^{52}=4,503,599,627,370,496 and 2^{53}=9,007,199,254,740,992 the representable numbers are exactly the integers. For the next range, from 2^{53} to 2^{54}, 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^{53}, you can face a rounding problem to the next even number.

Your failing odd account numbers are in the range of 2^{53} and 2^{54}:

09,007,199,254,740,992 (2^{53}, 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^{54} (= 2 x 2^{53}) 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