Hi Vince,
In my case, it wasn't to allow NULLS or not, but actually "REQUIRED". I had that as a AddField argument in my arcpy script to update my domains. Most the time I ran it against a new FGDB that I delete/recreate on each update, so it was never an issue. I'm currently updating my MASTER sde database and ran the script, which then added the field to that. I decided I didn't want that field in the master and then couldn't delete it. That is when I looked at my script and saw my error...
arcpy.AddField_management("master, "newField", "SHORT", 0, 0, 2, "anAlias","NULLABLE","REQUIRED")
Good suggestions about looking at the archived tables and metadata for issues after the SQL commands I performed. Especially the metadata. That didn't dawn on my that is could mess with that.
Besides not messing up my GDB topology/tracking/versioning/archiving, I was hoping to be able to keep the history intact, but I'm also wanting to reorder the fields (this is major overhaul of the master files), and I think the only way I can really do what I want is to use the "X-RAY" reorder tool which still wants to recreate the file (or errors out when trying to replace)..which mean the globals will be different and history may not follow forward anyway. But IF I am using the X-Ray option, I found the new file did not have the "REQUIRED" flag on the field in the new file and I could delete if in Catalog then, so I will have to mess with that approach. I'm also thinking of renaming the actual GDB too, and that also seems to be best with a replacement/rebuild. Anyway, just trying to retain as much history as posible, but those are diccussions beyond this thread.
Thanks for your suggestions.