We're working with a SQL Server database, and using the FID as a fixed record reference. And although the FID in SQL Server may be a 64-bit integer value, Ogr2Shape conversion always creates the FID as an Integer field. I believe that this is because the Shapefile source code only defines a 32-bit INTEGER data type - there is currently no 64-bit integer type defined.
The Xbase definition includes a Numeric data type field (code N) that holds up to 17 characters, including a sign and decimal point, that makes no distinction between integer or floating point. And in fact, this field is currently used by the open source Shapefile code for both Integers and Floating point values. However, the determination of data type is based on the following conditions:
IF Precision > 0 OR FieldWidth >= 10, THEN it is considered a floating point, else an integer.
I am recommending that we change the condition such that it is based solely on Precision > 0, independent of the length of the number. This would allow for values high into the 64-bit integer range. For backward compatibility, we could add a global setting indicating whether or not to support the 64-bit integer interpretation. Or, rather than globally, we could perhaps allow/apply the change on a per-Table basis (with a new OgrLayer property?). We could also propose an update to GDAL so that the codebase would be the same.
Please provide your thoughts.
1. Has this been an issue for anyone in the past?
2. Do you agree with the proposed solution?