FAQ: Why are tables or feature classes with user-defined unique ID fields not editable?
Why are tables or feature classes with user-defined unique ID fields not editable?
Anytime a feature class or table in an access database is in an edit session, a delta table is created to store the edits and allow the undo or redo functionality. This scratch table also stores the unique index. In the case of the unique ID field that is managed by the database, i.e., the OID field, the record is automatically updated to avoid a violation of the unique key rule.
The user-defined unique index fields are not managed by the system. If edits were allowed with user-defined unique index fields, then it would not be possible to have more than one feature or record stored in the feature class or table. The reason being that after the addition of the first feature, a unique key violation would be encountered even if the value in the user-defined unique index field was changed.
ESRI's developers previously tried to work around this limitation by experimenting with the idea of dropping the index fields in the delta table, so as to allow users to violate the unique key constraint during the edit session. If the duplicate unique records were not resolved in the course of editing, an error would still be returned when the edits were saved, since the unique index would be violated when the records from the delta table are moved to the feature class table. Even if the edits that violated the unique index rule were rolled back to the state before the edits were made, an accurate error message that indicates which features were the offending features could not be provided, so the end user would not have any clue as to what rows had duplicates in which class.
When starting an edit session with any feature class in a feature dataset, all the feature classes are opened for the edit session. If a feature class in a feature dataset has a user-defined unique ID, none of the features in that dataset can be edited.