Provide options for *when* to validate attribute data against domains, e.g. not just when explicitly requested

[danan]

Domain-constrained attributes are only checked for compliance when a user explicitly requests it. This is like asking someone filling out a web form to remember to click a special Validate button after hitting Submit. An ArcGIS editor who doesn't consistently perform validations could leave a difficult-to-correct data quality mess. Upon later discovery, sufficient time may have passed that the original editor doesn't remember which value is correct. Worse, someone other than the editor may have to conduct research to determine the correct value.
 

The way domains are currently implemented (especially with range domains), high data quality seems only a suggestion or a potential. It is more optimistic than I that myself or others will make mistakes yet not forget to check for them. Compliance should be the the data modeler's decision and the geodatabase's job. Once an attribute is associated with a domain, editors shouldn't have to ponder whether and when a validate operation is required.
 

When assigning a domain, please consider providing the data modeler options such as:

* VALIDATE - IMMEDIATELY (and make this the default)

* VALIDATE - DEFERRED (should be the rare case and explicitly requested by the modeler)

VALIDATE IMMEDIATELY would reject illegal data values and alert the editor either when focus changes from one field to another. Or when she saves edits. Perhaps akin to validation by individual SQL statement or by transaction.
 

VALIDATE DEFERRED would be the current geodatabase behavior--perform validation only upon request.

There may be other variations. But I think a VALIDATE IMMEDIATELY option (on change focus) would make sense here.

While there may be good reasons for not interactively validating geometry, I don't see any for attributes (at least not as a default behavior). Is this a vestige of development or are there strong, still-currently-relevant reasons for defaulting to deferred attribute validation? Hoping to learn my take on this is bogus--because then I'd be unlocking more value in the geodatabase. As it stands, this deferred validation approach has me stumped (evidently easy to do).

[BugmeNot]

I discussed this with Esri software development 10 years ago.

This was the reply:

"ArcGIS will never PREVENT a user from entering invalid data - it will just warn them when they do so and report invalid data when 'validate features' is run from the edit toolbar.

In order to warn the user when they are editing a table directly (for feature classes) you can check the 'Automatically validate records when editing' on the Tools | Options | Tables dialog in ArcMap.  After each edit on a table cell, validation is run and the user is warned each time they edit a value that is not allowed by domains. NOTE: Editing done via the field calcuator is done outside an edit session. Validation can only be triggered inside an edit session.

This is to allow maximum flexibility for users - many have complex business rules that cover geometry, attributes and related features. If users were restricted from making atomic edits that are part of a larger more complex editing workflow (a logical edit):

* it could become impossible to enter valid features at all
* it would affect performance
* it could also present a deadlocked application to the user

This is why validation rules are not enforced every time any geometry, attribute or related feature is changed - since in many cases more than one atomic edit is needed to create valid data.

Let's say a geodatabase is setup to prevent users from creating a parcel record without a related owner record (and the reverse).  With automatic enforcement at the atomic edit level, users would be unable to create either record. Both changes involve a series of atomic edits, so validation needs to be performed after the logical edit - not after each atomic edit.

I'd suggest you contact ESRI Technical Support and have them look at your editing workflow if you want to share more information with ESRI Development about how this design decision affects you."

[danan]

Bugmenot, thanks for the excellent explanation.