Allow Field Precision and Scale to be Defined in Feature Class Wizard

mpboyle

When adding a "double" field type in ArcGIS Pros Feature Class Wizard, please allow precision and scale to be defined if using an enterprise geodatabase.

For example: if I add a double field to an enterprise geodatabase dataset within the wizard, the precision and scale can not be defined, and this results in them being 38,8. In most of our use cases this far exceeds any precision and scale we'd use and bloats the table. If I want to alter the precision and scale, I have to manually do it through the database interface like SSMS.

SSWoodward · ‎05-08-2025

Thanks for sharing your frustration @mthompson. I totally get it, and this Idea is being examined by the team.

In the mean time, passing the class as a template to the Create Feature Class GP tool, and not the wizard, will bring along existing precision and scale values from the template class in to the newly created feature class in an enterprise geodatabase. It is accurate that the wizard does not provide functionality to set precision and scale in the current version of ArcGIS Pro. The wizard will set precision and scale to their default settings based on the datatype.

mthompson · ‎05-09-2025

Thank you for the workaround, I tried using a file GDB feature class as a template to import into an enterprise GDB and it defaulted Double fields to 38/8 which will at least be able to accommodate my longer values.

PhilippeChesselVdG · ‎06-18-2025

Same issue with a Enterprise Géodatabase (ORacle 19.x, géodatabase sde 10.9.1 ou 11.3_3.3.4)

And ArcGIS Pro 3.3.4

The default of the Float data type in the database is created as 6.1

The default of the Double data type in the database is created as 7.1

This is problematic as soon as you want to create décimal fields like coordinates 😞

The 6.1 and 7.1 defaults are not visible on screen when creating the feature class

Please, we need then to be able to modify while creating Double end Float fields the scale/precision

PhilippeChesselVdG · ‎07-15-2025

Same comment again, with ArcGIS Pro 2.9 to 3.3 migration, with this behavior of default Double as (7.1) and FLoat as (6.1) numerics.

The default is so useless when a user think of creating Double or Float (latitude, longitude, X, Y fields, ...)

And having to tell the end users that they have to use "Add Field" wizard for every field of the new class or table is not comfortable.

The Field Designer does not allow to modifiy the precision/scale of existing fields.

Is there eventually other ways ?

Thanks

Michele_Hosking · ‎08-06-2025

This is so frustrating - who thought 7/1 was a good default? I even tried copying my feature class from enterprise to a fgdb to change the precision - precision doesn't even show then. You can't even use the Create Feature Class wizard and use a template to pull in the fields because it just uses the same as the template without the opportunity to change anything. I'm trying to fix one field out of 44 in a feature class. What - I have to create it with no fields and put in 44 fields again manually in order to sort this? Why was this functionality ever removed? Why was the default for double made 7/1? Does anyone who makes these decisions actually do any real work? It so frustrating.

Oh and P.S - you can't use the Export Feature Class to Feature Class either....

And while we are on the subject - why has the max length of a field name dropped from 30 to 29 characters? 'Cos I'm currently re-making my feature class from scratch and I can't even copy in a field name that already exists in a current feature class as it has 30 characters - now I have to change the name of a field because it won't fit!!! OMG - it just gets worse - 'cos this feature class is everywhere. You know the hoops I have to jump through if a field name changes? And don't quote me on this but I'm pretty sure a few years ago (maybe ArcMap??) the max field name length used to be 31.

Ok - because of the field length issue above this is what I have to do to get around everything...

Export fc to fc and remove offending field in the process (in enterprise 'cos you can't even see the precision of a new double field in a fgdb let alone change it)
Add the field into the fc copy - but now - you know - the field is at the end of the list of fields and not where it's supposed to be so...
Export the fc copy to fc copy 2 and move the field in the process
Truncate and append the data from the original fc to copy 2 as you've lost all the data in the offending field
delete the original and copy 1
rename copy 2

After all that when I changed the precision to 10/2 it's actually changed it to 38/8. Oh well - small wins I guess....

What a palaver.

RonnieRichards · ‎08-07-2025

@Michele_Hosking Agreed this is frustrating! To provide a little more background to some of what you encountered:

File, Mobile Geodatabases and GeoPackages do not technically have decimal data types with precision, they are all considered float which is why you get the 38,8 definition.

However the experience of designing data models in the Enterprise geodatabase has been completely destroyed. Creating data models using templates used to be a very productive workflow, now it no longer works due to this 7.1 madness. At our organization we now create all of our data models in unregistered tables using the RDBMS tools and then register them with the geodatabase when confirmed.

Any changes to these then encounter all of the issues you and others shared on this thread. We use backend rdbms tools to modify column definitions in non-versioned environments due to all of the hoops required using Pro management tools.

Educating new users and staff with the work arounds and other approaches make very little sense, please just fix this tool to work like it used to allowing users to alter decimal precision where applicable.

Michele_Hosking · ‎08-07-2025

@RonnieRichards - thanks for the suggestion. I might try RDBMS tools as well. The world is a funny place. Things that work get broken and things that are broken are never fixed. Entropy I guess.....

SSWoodward · ‎08-07-2025

Thanks everyone for continuing to share your feedback.

@Michele_Hosking At ArcGIS Pro 3.5 the maximum field name length has been increased to 128 or the maximum allowed by the underlying databased platform, whichever is less. This should address the naming issue you have shared. What's new in 3.5

@RonnieRichards is correct, there is no concept of user defined scale or precision in geodatabases other than enterprise geodatabases.

@RonnieRichards you also shared that;

"Creating data models using templates used to be a very productive workflow, now it no longer works due to this 7.1 madness"

Can you share the version of ArcGIS Pro where this workflow changed for you? Or was this a workflow in ArcMap that is now disrupted on a migration to ArcGIS Pro?

mpboyle · ‎08-07-2025

@SSWoodward

To the best of my knowledge, having the ability to define precision and scale, specifically on the Create New Feature Class/Table interface has NEVER been available in Pro.

This IS available in ArcMap/Catalog, and as many commentors have mentioned, having this ability seems rather simple given that it's available in ArcMap/Catalog and for certain Pro tools (ex: Add Field tool), and its omission is frustrating, especially going on 10 years of having Pro.

Pro Create New Feature Class Interface --- this is an enterprise geodatabase --- no ability to define precision and scale in the field properties

ArcCatalog Create New Feature Class Interface --- same enterprise geodatabase as above --- ability to define precision and scale

Pro Add Field tool --- Precision and Scale ARE available

SSWoodward · ‎08-07-2025

@mpboyle yes that's correct. The feature class and table wizards have never had the ability to set scale or precision in ArcGIS Pro.

There are lots of clever users who make use of the software in unexpected ways, so I was hoping to get more information about the workflow to make sure I was on the same page as everyone with what was being shared.