Latest Contributions by ColinWerle1

It is typically not recommended to manually edit the geodatabase items through the backend because it can lead to unexpected behaviors. In this circumstance restoring a database backup is likely the safest solution. If you restore the database to the condition prior to unregistering as versioned, do you see the Definition field populated? It may be a good idea to do a clean export and re-import of the data from that backup. When you export the feature class to a file geodatabase and re-import it, it will not be registered as versioned. However, it would be worth going through the workflow of registering and unregistering as versioned to see if the issue persists.  ... View more

In that case, I would avoid saving passwords on the admin connections when you create them, which is typically a good habit to practice in general if you can. Here is some other good doc as well: User accounts and groups—Help | Documentation ... View more

Hi Neel, If you have a headless account (db authentication) creating/owning the data, managing domains, etc. you will not have to worry about future user changes to the environment (e.g. user turnover, new users, etc.). A headless user can be easily managed by a single user, or multiple, and you can change the password as you wish if necessary. If the geodatabase system tables are owned by sde, then that sde user mapped to the geodatabase is your geodatabase administrator, no need for a new user called "sde_admin". OS authenticated users are certainly helpful for efficiently tracking edits, versioning, etc. in the geodatabase. So if you would like to use OS authenticated users, then it sounds like a possible configuration could be having a db authenticated user create the data and domains, then map OS authenticated users to the database and grant necessary privileges on the datasets that they will be editing. Extra documentation: Privileges for geodatabases in SQL Server—Help | Documentation  Modifying and deleting attribute domains—ArcGIS Help | Documentation  Hope this helps! Colin ... View more

Hi Yatharth, Did it participate in SQL Server replication or enterprise geodatabase replication?  Objects published via SQL Server replication cannot be dropped or renamed. This could be expected behavior and may not have to do with the geodatabase itself. If you want to delete or rename a feature class that participates in SQL Server replication you would first have to remove the object from the publication, or disable replication. ... View more

Hi Dylan, I suggest re-posting this on the https://community.esri.com/community/arcgis-ideas page for greater visibility! ... View more

Hi Alfonso, I believe a related conversation is happening over at Auto-Increment Field within SDE. There should be some information throughout that thread that you may find valuable to your workflow. Colin ... View more

Mike, I just did some brief testing. What I found was that I am able to increase the field length when the table is unregistered as versioned, however, if I tried to decrease the field length I would be prompted with a "table or feature class is not empty" error. Colin ... View more

Hi Mik, Typically it is not recommended to follow this workflow because of the version view table. A possible workaround could be to un-register it as versioned in ArcMap, and use the field properties dialog box to change the field length, then re-register it as versioned again. Best, Colin ... View more