I am trying to customize my database to include better quality control. There are some fields that I never want null. So, I go to "field design" and attempt to unselect the "Allow NULL" option in the fields I would like to never have blank, but they are all "grayed out" and I cannot change them. See the screen shot below:
Any ideas how I can fix this issue?
Solved! Go to Solution.
Is your database a file geodatabase by chance? My guess is this is not availabe in the file geodatabase format. If you are using a RDBMS such as SQL Server, you can use SQL Server Management Studio to set a "not null constraint" on an attribute field.
In SQL, it would be:
alter table <owner>.<feature class>
alter column <column name> int not null
Hope this helps!
If the gdb contains data, it can't be changed
Modify field properties—ArcGIS Pro | Documentation
Is your database a file geodatabase by chance? My guess is this is not availabe in the file geodatabase format. If you are using a RDBMS such as SQL Server, you can use SQL Server Management Studio to set a "not null constraint" on an attribute field.
In SQL, it would be:
alter table <owner>.<feature class>
alter column <column name> int not null
Hope this helps!
I am trying to complete this for a table (in a SDE). Can you tell me what is wrong?
Yes, remove the < and > - these are not needed rather just to indicate it's an owner name and table. Based upon your text it would be:
alter table mcgis.service
alter column guid int not null
Let me know if this works for you or not. Thx!
I ran same SQL Statement to alter field properties and it is showing as expected in SQL Server Management Studio. when I try to open EGDB in ArcGIS Pro , It shows Allow NULL as checked and does not change and it is in disable mode
Would the reverse also work? We have numerous enterprise geodatabases on Microsoft SQL Server, with many feature classes containing multiple fields that we would like to set as nullable. They are currently not nullable.
I can understand the requirement of the table being empty for going from nullable to not nullable fields, as you could end up with invalid data otherwise, but do not understand the need for the constraint when going from not nullable to nullable - in this case, more values (i.e. null values) are permissible.
We are not currently in a position to replace or rebuild all of our feature classes for what should be a simple change, and hoping that a tweak to the underlying RDBMS, similar to what you proposed, may solve our issue more simply.
Otherwise, we'll have to plan for a much larger set of work to rebuild everything at some point, to allow null values in out schemas; this is somewhat complicated by the need to maintain GlobalID values and editor tracking values, etc.
Thanks for any advice on this.