Latest Contributions by KimOllivier

When importing data from geopackage or sqlite any field defined as Integer in the DDL gets cast to BigInteger instead of (Long) Integer. This is a new incompatible behaviour since BigIntegers were included (ArcPro 3.2?). There are several tools that do not work with BigIntegers such as RelationshipClasses. It would be helpful if there was a switch to turn off this unwelcome enhancement. There is a switch in Options/Map and Scene - but it doesn't work. The only way to fix the problem is to define a FieldMapping on every copy operation and there are many of these that do not have FieldMapping as a parameter. If the field is readonly such as OBJECTID then it cannot be changed at all. I see another user has used FME to fix this. This is like a reverse single precision / double precision incompatibility! Maybe a switch somewhere in the settings or the environment settings to retrofit a fix? ... View more

ArcGISPro is apparently backward compatible with ArcMap but I have found a serious limitation in the TableToRelationshipClass_management tool when finally upgrading my scripts. ArcGISPro will only accept GlobalIDs or String fields as keys and only String fields in the relation table. What has happened to Integer fields? These were apparently Best Practice in database design for Primary and Foreign keys. Edit: it appears that Big Integers are not supported, Short and Long are allowed, but if a sqlite table is being translated INTEGER type is by default typecast to BigInteger. But these are not supported in Relationship Classes. I have a clone of a large survey database ( 50 tables, 70 GB) that uses Integer for nearly every table which I use in the relationship class definition. There is also a sequence field used to order related records that is integer (of course). Choices: a. I could adopt GlobalID - GUID relationships. This is a lot of additional work, not in the source tables. The GlobalID is readonly and not under my control. It can be changed arbitrarily by Esri tools if they consider the feature is "new" thus breaking the link to the foreign key. b. I could copy the integer keys to strings just for the relates. This is also a lot of work (60 min processing per relate x 5 relations, indexing, rebuild the relate. At least I am still in control and the keys are static. I do not do any editing except for bulk validation, subsets, copies. c. Force a cast of all integers in the entire database to Long instead of Big Integer when translating. Using string values for integers does work but takes over an hour to build the relation class. using GlobalID-GUID pairs is faster at 7 minutes. The proper solution is to return to basics and somehow force the cast to Long everywhere. To do that I found I had to remove deprecated tools TableToTable and MakeFeatureLayer/CopyFeatures with tools from the Conversion toolbox: ExportTable and ExportFeatures which have a parameter to include a FieldMappings/FieldMap/Field expression that allowed me to override the default and change the field_type before copying to a filegeodatabase. I also had to replace the simpler FieldInfo parameter which does not allow type mappings. If you are only doing a couple the interactive tool lets you define the fieldmap, but in Python it is a nightmare of obscure FieldMapping objects. If only there was an environment variable to switch the default Integer type to Long instead of BigInteger. ... View more