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

[HarryBowman]

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]

I expect it is a DBF issue -- the buffer is 14 places, and it uses scientific notation.  If you write
one row out to the shapefile, you could open in an editor and look at the file contents.

- V

[HarryBowman]

Thanks, Vince.
The original shapefiles (before bringing them into gdb via a merge) had the 14 (or 15 in some cases) ID as a double field.
When I took one of the original vendor supplied shapefiles, opened it in ArcMap, the ID showed up fine. I selected one record and exported. The new dbf showed up fine - the entire ID was there. Opened in an editor - the ID was there, no scientific notation.
Took a file GDB table with the same ID field. The entire ID is there in file GDB. Selected one record and exported as dbf. Opened the file in an editor. The ID field was truncated and used scientific notation, as you predicted.

[VinceAngelo]

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

[JoeBorgione]

... 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]

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

- V