Note: This topic was updated for 9.3.1.
To help ensure data integrity, the geodatabase provides the Allow Nulls field property, domains, subtypes, relationship classes, and default values. Similarly, the DBMS provides its own data integrity features, including null constraints, unique constraints, referential constraints, check constraints, and triggers. ESRI recommends using geodatabase features instead of DBMS constraints and triggers to ensure data integrity. The geodatabase features are more forgiving, more powerful, and work the same in all the DBMSs and personal geodatabase formats.
However, if you have a third-party application that accesses the data in your geodatabase, the application can only access the data at the DBMS level, bypassing any of the integrity features you set up at the geodatabase level. To support this application, you may want to implement DBMS constraints and triggers.
When you edit data in a nonversioned edit session, edits are subjected to any DBMS constraints established on the data. Whenever you perform an individual edit operation from within ArcMap or an application written in ArcObjects, and it violates a constraint, a message from the DBMS displays informing you of the error. Similarly, editing in a nonversioned edit session also activates any triggers—if an edit updates a column that has a trigger defined on it, the trigger fires.
