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.
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.
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,...)