export file gdb to dbf rounding doubles - any way to avoid this bug

Question

I ran into this yesterday but found it was a bug submitted (in pgdb form) back in 20007. I have 14 digit IDs from a vendor that are A-OK in shapefile as doubles. Copy into file gdb - no problem. Export out to dbase and the last two digits are 00. It must not be a limitation of the dbase format, because all 14 digits are in the original shapefile. I've tried GP tool and from ArcMap UI.

Has this really been a bug for 5 years? I can think of two work arounds: export as text file and write the IDs into text fields. It'd be a lot better if there was some way to avoid the whole thing.

NIMBUS still shows that bug as "on hold."

VinceAngelo · Answer

That's me -- concise and non-eloquent. 😉

- V

JoeBorgione · Answer

... so I wouldn't consider this a bug; it's just
a manifestation of one of the many reasons shapefiles are not reliable as a spatial data
transfer format.
- V

Vince- that is probably the most concise if not eloquent description of shapfiles I've ever read.

VinceAngelo · Answer

There's two ways to represent numeric values in dBase, floating point and scientific notation.
It's not possible to encode values in either without running into precision issues, and SciNot
has a much larger range.

I don't trust double precision past 12 places, so I wouldn't consider this a bug; it's just
a manifestation of one of the many reasons shapefiles are not reliable as a spatial data
transfer format.

There are a number of ways to retain the value of your IDs that are transfer-safe, but
all of them involve converting the values into strings (base16, base32, base48,...)

- V