topic Re: field calculator allows non-domain values in Geodatabase Questions

field calculator allows non-domain values

GeorgeRiner — Thu, 23 Mar 2017 23:24:07 GMT

We have a polyline feature class (in our enterprise sql geodatabase) with a couple attributes that have domains specified. During the usual manual editing of features, it works like a charm - users can only select one of the defined values in the attribute's domain. But the Field Calculator allows any (string) value to be placed in the field, including string values that are neither a domain code nor domain description. I get the same problem in Python code using arcpy.UpdateCursor.

If somebody starts an edit session, enters invalid attribute values (i.e. non-domain) into ~200 features and then saves the edits and walks away - ArcGIS doesn't even blink an eye. I have to start up the editor again, select those ~200 features (in my case, across 5 feature classes) and then run "Validate Features" to have ArcMap bark at me about "Field xxx attribute value yyy is not a member of coded value domain zzz".

Rather defeats the purpose of using a domained attribute.

What do others do?

Re: field calculator allows non-domain values

DanaNolan — Thu, 30 Mar 2017 17:17:09 GMT

Thanks, I did find something new thinking about your question. I believe there used to be a way to set the option to validate immediately when editing, but I doubt this worked with field calculations.

First, what I do now is summarize my domain-enforced fields periodically and/or do joins to an external domain table (exported from the domain and/or turn the show "display coded attributes..." button on and off in a table. This last method will make all the bad values pop out (because they won't change), assuming your domain description field has a longer/different text than your domain code, which makes them easy to fix.

The new thing: http://desktop.arcgis.com/en/arcmap/latest/manage-data/editing-attributes/applying-the-same-attribute-values-to-multiple-features-in-a-layer.htm

You can do quick global edits of domain-enforced fields using a drop down list without using field calculations by using the Editing Attributes window. Maybe you could train some of your editors on this method. I don't use the Attributes window much except for annotation because I don't like looking at records one at a time, so I might never have found this feature.

Re: field calculator allows non-domain values

JTessier — Wed, 17 Apr 2024 15:13:52 GMT

This should not happen right @jill_es @NanaDei ? We have the same issue where domain values are set, but data editors can calculate values that do not match the values. Is there a way to really prevent this? We are using PostgreSQl in Azure as our SDE database.

Re: field calculator allows non-domain values

JTessier — Wed, 17 Apr 2024 15:22:33 GMT

Also seeing this related post about probably the same issue: https://community.esri.com/t5/arcgis-pro-ideas/prevent-non-domain-values-from-being-used-across/idi-p/1185679

Re: field calculator allows non-domain values

NanaDei — Thu, 18 Apr 2024 00:55:00 GMT

Thanks @JTessier, the goal can be achieved by authoring a constraint attribute rule as mentioned in the link you shared.

Re: field calculator allows non-domain values

JTessier — Thu, 18 Apr 2024 01:24:36 GMT

Hi @NanaDei I believe the original poster @Bud of the other suggested (and I agree) in his original post that custom attribute rules are not the preferred solution. If we had to enforce domains with a custom attribute rule for each table in our 400+ layer data model, that would likely be unwieldy/unmanageable. When as both ideas state: "I’m aware similar functionality can be achieved via customization using attribute rules or database triggers. But we shouldn't need to write custom code to enforce a pick list. Most enterprise systems have hard domains built in as a way of enforcing basic data integrity. For example, in IBM Maximo, the entire system honors domains by default — including back-end Python scripts. As a result, data integrity is rock solid, making data analysis easy."

Do you see another mechanism Esri can pursue to force domain values be respected as one would expect, as requested by this poster as well?

Re: field calculator allows non-domain values

Kevin_MacLeod — Fri, 22 Aug 2025 15:40:13 GMT

@JTessier 100% correct. This should be a checkbox option.

The "do it in python" to fill in basic feature gaps in Pro and the full stack takes all our time away from creating custom apps and doing high-end analysis. I spend a lot of time creating workarounds, fixing Esri bugs, or developing functionality for the backend with python and frontend with JS/CSS/HTML that should be in the product. Less focus on AI, VR, 3D etc and more focus on basics. We can do the fancy stuff ourselves. And that will differ customer to customer. It's the plumbing that's the same customer to customer. I saw something about them putting effort into AI for their docs for example. I already use Gemini for 90% of my lookups on Esri Docs, it's good enough. Gemini can't make domains work like they should, though.