Geodatabase table as dynamic feature class domain

Question

In ArcGIS Enterprise, is it possible to use a table stored in a geodatabase as a domain for a field in a feature class stored in the same geodatabase, such that it dynamically updates as new records are added to the table? Or do I have to use the table to domain tools each time I add new records to the table?

The idea would be to have a feature class of assets, and a table of owners, and restrict the values of the "asset_owner" field in the feature class to the entries in the table of owners

• Vince: You've got a chicken-egg problem here, since a domain defines what is allowed in a field. Auto-populating a domain with whatever comes along doesn't meet the design goal of restricting data to permitted values.
• Alex: I guess the idea would be to have a list of infrastructure owners, and restrict values in the feature class to the entries in the list of owners, to enforce some consistency.
• Kirk Kuykendall: Maybe add your vote here: community.esri.com/ideas/5768
• Son of a Beach: @Vince - technically a domain does NOT define what is allowed in a field. It only restricts what you can enter when performing manual edits, one record at a time. Eg, the field calculator or append tool can enter any value whether it is within the domain or not, as can other tools. (I so wish this was NOT the case, or at least that it was optional, as it would resolve so many problems with importing bad data from 3rd parties.) So data is never actually restricted to the domain values anyhow.
• PolyGeo: @KirkKuykendall I think your comment could easily be expanded slightly to create a valuable answer.

Answer 1

I haven't tried this, and there are serious problems with it (see below), but...

Using your SQL management software for whichever database platform you run, create an INSERT/DELETE/UPDATE trigger on the database table that you want to use as your domain source. The new trigger should include an SQL command to execute an external Python script (AFTER the insert/delete/update).

The Python script can then run the arcpy.TableToDomain() tool to update the domain automatically every time the table is updated.

It's messy (I dislike the obscurity of triggers in general), plus...

Of course arcpy.TableToDomain() is likely to fail if anybody has a lock on the database schema (which is going to be likely any time somebody is updating that table!), so in reality this is not practical. You could work around this by forcefully disconnecting all users before running the arcpy.TableToDomain(), but of course that is very disruptive and could result in lost work. So again, not practical.

So the next best option would be to run the script on a nightly schedule at a time when users are unlikely to be connected, instead of being run by a database trigger. This is how I've done it in the past, but it means that your domain is up to 24 hours behind the current table values.