Many ArcGIS users use geodatabase domains to allow data editors to enter for certain attributes only certain values, either within a range or from a set of coded values. This functionality streamlines data editing and is very helpful indeed. However, having a geodatabase domain set for a field doesn’t actually prevent users from typing in value that is either outside of range or not in the list of coded values.
Entrance of illegal values can be done either programmatically using
SQL or by editing the attribute table of a feature class using
Field Calculator. To be able to find out which features have illegal attribute values, you would need to select all of your features in the editing session and click
Editor > Validate Features. This will select features with illegal values.
But what if you would like to let your users pick only certain values when editing the features and prohibit entering any illegal values? To do this, you could use database constraints such as foreign key constraint. In fact, I have already answered this exact question on GIS.SE: Restrict values to domain codes (beyond the attribute table).
In the end of the post, please look at the code snippet of what should be done in SQL.
Now you can just use GP tool Table To Domain which will let you create a geodatabase domain from the
dbo.CityType table as well as add the coded values into it. Then you can assign this domain to a field Type in the
Cities feature class using the GP tool Assign Domain To Field.
Now user will get an error window in ArcMap (returned from SQL Server) every time they will try to enter illegal values into the field and save the feature. One thing to keep in mind when embracing this workflow is that you’d need to go to
Editor toolbar > Options > Attributes tab and enable the option
Display the attributes dialog before storing new features. This is necessary to do if you don’t specify any default value for this field that is stored within the
dbo.CityType table. In this case, newly created features will have no value associated with the
Type attribute and you won’t be able to digitize a feature on the map without getting the error message.
Another thing that may bug you is the geodatabase topology. It’s very handy when you have inherited a large suite of feature classes and you would like to enforce some integrity rules concerning the spatial relationships between features in those feature classes. However, if your data is stored in a multi-user geodatabase, then you could create own rules that would prohibit users from creating features that break those rules. Using ArcGIS geodatabase topology it is still possible to create a feature that would be considered invalid in terms of its relationship with another feature (say school point inside a lake polygon), however the only way to find this out is to validate topology on existing features.
Using SQL Server triggers, it is possible to specify the spatial rules and prevent creation of features that don’t follow these rules. Below is a simple example of a trigger that won’t let ArcMap users to digitize a point on the map to create a point feature that is located outside of the boundaries of the California state.