nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Apply Asset Package: float changes to double in enterprise geodatabase

Andy_Morgan

I'm using ArcGIS Pro 3.0.3 (UN schema version 3, untools version 3.0.0). Apply Asset Package changes my Float data type fields to Double data type in the output enterprise geodatabase.

Is this a known bug? Is there any way to prevent this conversion? Was it fixed in 3.1 or later? I don't understand why this happens if Float is a valid data type in EGDBs, too. Why can't it be retained? If asset packages cannot handle Float then that means I change my entire workflow and create all of them directly in the EGDB...which makes for a very inconvenient deployment preparation. Not only that, if you were to export the EGDB to asset package and bring it back in, you'd have to re-create all your fields again? ...or just accept Double 38 precision, 8 scale, instead of Float which is not ideal if you want to limit numbers, have smaller decimal places and save a little data storage.

Find more posts tagged with

Accepted answers

PaulLeBlanc1

untools 3.1.1.1 is uploaded here and can be used like so. This is a RC build, so caveat emptor, not supported, etc. Please reach out to pleblanc at esri dot com (or direct message me here) with any issues/questions.

import untools
import arcpy

# Override precision and scale for all float fields.
untools.common.settings.SINGLE_PRECISION_SCALE = (6, 1)
untools.common.settings.DOUBLE_PRECISION_SCALE = None  # The default.

arcpy.pt.AssetPackageToUtilityNetwork(...)

To install, open a python command prompt and run conda install solutionsdev/label/pro3.1::untools

PaulLeBlanc1

The code above was to show that despite telling the system to create a FLOAT, it created a DOUBLE (implicit upcast). There is a very specific edge case where apply AP does explicitly upcast a FLOAT to a DOUBLE (i.e., it creates the field as a DOUBLE to begin with). You get a runtime warning informing you about this.

If you create a FLOAT field and don't specific scale/precision, then you get a DOUBLE. Tested with the same software as above, so you'll see this behavior even after you upgrade your client.

Edit:

Apply AP has been creating FLOAT fields with the following payload since ~Pro 2.1. Scale/Precision are both 0 because that is how they are stored in FGDB.

<AddField>
   <field_name>f_05_03</field_name>
   <field_type>FLOAT</field_type>
   <field_precision>0</field_precision>
   <field_scale>0</field_scale>
   <field_length>4</field_length>
   <field_alias>f_05_03</field_alias>
   <field_is_nullable>True</field_is_nullable>
   <field_is_required>False</field_is_required>
</AddField>

All comments

Andy_Morgan

Awesome, thanks so much Paul. I don't have Pro 3.1, but soon enough I'll upgrade and try this out. This seems like a good solution for most people (...who care at all about precision/scale properties).

PaulLeBlanc1

import untools
import arcpy

# Override precision and scale for all float fields.
untools.common.settings.SINGLE_PRECISION_SCALE = (6, 1)
untools.common.settings.DOUBLE_PRECISION_SCALE = None  # The default.

arcpy.pt.AssetPackageToUtilityNetwork(...)

To install, open a python command prompt and run conda install solutionsdev/label/pro3.1::untools

Andy_Morgan

Same result here with my version of SQL Server: changes over to Double at the "f_07_01" field (precision > 6).

This clearly illustrates what happens in general when manually creating new fields. I was mainly wondering if anyone out there can confirm "Apply Asset Package" still converts from Float to Double in later versions of Pro / UN schema (3.1+). If I need to upgrade one of our test computers and run through the whole process on it then I will, but there must be many users already on 3.1 right now who have tried this. I'm not totally clear if you're implying the answer is yes (3.1 and higher also convert Float to Double). If that's the case, then I'm confused on how Apply Asset Package is not "explicitly upcasting the field" and yet the field is in fact different in the target EGDB.

PaulLeBlanc1

I'm testing with Pro 3.3 and SQL Server 16.0.4120.1 (what I have handy).

import arcpy

fields = []
for p in range(1, 10):
    for s in range(1, p):
        fields.append(
            dict(
                field_name=f"f_{p:02}_{s:02}",
                field_type="FLOAT",
                field_alias=f"Precision: {p}, Scale: {s}",
                field_precision=p,
                field_scale=s,
            )
        )

for f in fields:
    arcpy.AddField_management(
        r'<my table>',
        **f
    )
    print(arcpy.GetMessages())

The fields are created as numeric(p, s), but ArcGIS treats any precision >6 as a DOUBLE:

Andy_Morgan

Paul, I really do appreciate the quick responses on this board. I'm using SQL Server:

Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)

While this is a development server hosted on a virtual Windows server, the SQL database is nearly identical to our production server where I'll eventually deploy our UN within 6 months. Here's the production server version:

Microsoft SQL Server 2019 (RTM-CU19) (KB5023049)

I'm trying to think if there is anything else special about what I'm doing. I don't want to waste anyone's time. Let me know if you think of anything else that might be different from the normal scenario. Even though FGDB don't support scale/precision, it still surprised me that it was casted differently for this particular process/tool. I will eventually upgrade Pro to 3.1 and could re-try this process, but I figured others out there with 3.1+ already know if it does or doesn't work.

PaulLeBlanc1

File geodatabases don't support scale or precision (https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/add-field.htm) so round-tripping is problematic unless we stored the desired scale/precision in a side table and read from that during field creation.

What DBMS are you targeting? untools is not explicitly upcasting the field, so I'd need to dig further to understand where that is happening.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.