Community

Attribute Rules should be enforced at the Database level

736
1
03-19-2020 02:02 PM
Status: Open
JohnMDye
by
Occasional Contributor III

Currently, attribute rules are only enforced and applied if edits are made through ArcGIS Pro or a Branch Versioned Feature Service. This is okay, but since Attribute Rules are essentially a method for implementing database triggers, they should be enforced at the Database level. How the data is edited on a Feature Class in a File or Enterprise Geodatabase should be (mostly) irrelevant.

 

If I want to update it with a SQL script, that shouldn't be a problem.

If I want to update it with a Python script, that shouldn't be a problem.

If I want to update it in ArcMap, ArcGlobe, ArcScene, that shouldn't be a problem.

 

Bake the logic directly into the File and Enterprise Geodatabase so that I can update the data however I want and not have to worry about what client my customer is using to edit my data with.

1 Comment
AndrewQuee
by
‎09-01-2022 06:56 PM

I might be misinterpreting what you're saying but my understanding is that attribute rules are indeed baked into the geodatabase:

https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/an-overview-of-attribute-ru...

"Attribute rules are created on an input feature class or table."

"...attribute rules are established on datasets in the geodatabase..."

"Once attribute rules are added to a dataset, it is incompatible with ArcMap or ArcGIS Pro 2.0 and earlier."

So, only compliant clients can even edit the rules-based geodatabase objects, and if they do they are required to follow those rules regardless of how they did it (GP tool, python, arcade, scripting/model, version edit, etc).  This is pretty much exactly what the community asked for, and is a relatively simple and elegant solution.  (Needs improvements of course, but that is happening)

Can you edit the underlying database by using native tools bypassing the Esri stack or build your own triggers/database scripting for custom functionality?  Sure... but do you really want to go back to the good-bad old days of ArcView 8/ArcInfo?

I believe when this has been mooted in the past Esri didn't want to get in to modifying/supporting changes to propriety RDBMS' and they have no no way of knowing which one you use; a massive cost on their business to essentially change multiple companies products.  The answer was...  Attribute Rules on the Geodatabase extensible through web services.

As long as you're in the Esri ecosphere I don't understand the problem, unless you're dealing with non-Esri clients who are directly editing the database, or you're importing data directly without going through an edit/rules/reviewer QA process.