field calculator allows non-domain values

[GeorgeRiner]

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?

[DanaNolan]

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-attribut...

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.

[JTessier]

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.

[JTessier]

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-...

[NanaDei]

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

[JTessier]

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?