Can't delete some SDE fields.

878
4
07-10-2017 10:11 AM
DanaNolan
Occasional Contributor III

Using my highest level (SDE) connection, there are some fields I cannot delete in many of my older feature classes. They are all old (SDSFIE 2?) primary keys, I think, but I see nothing different about them in the field and table properties. They are not used in indexes, participating in relationships, subtype fields,  or otherwise special.

The data has archiving enabled but not edit tracking or replication.

0 Kudos
4 Replies
George_Thompson
Esri Frequent Contributor

Who is the data owner of the table?

--- George T.
VinceAngelo
Esri Esteemed Contributor

The SDE user login is not the highest level of access.  In fact, it shouldn't have any special privileges at all, and, as a rule, should not ever be used.  The table owner is the highest level of authority for any specific table and the RDBMS administrative user, which technically trumps owner, shouldn't be used at all (huge denial of service risk).

- V

DanaNolan
Occasional Contributor III

I am using the only connection that lets me do schema changes. So it is MY highest level of access. The point of the question was that I can remove any other field I want to except this field.

According to ArcCatalog, SDE is the owner of the table (it was set up that way years ago, so I can't explain why, except that it is behind an extreme level of firewall protection.) As far as not using SDE user, we were forced  suddenly into Operating System Authentication, but it did not work correctly for schema changes and perhaps has other issues, otherwise, I would have been able to stop using database authentication. I am the DBA for GIS, but not the SQL Server admin.  

0 Kudos
VinceAngelo
Esri Esteemed Contributor

Please state which fields you cannot delete. Some RDBMSes do not support DROPping any columns, so explicitly stating the RDBMS in use and the exact version, with the exact versions of Desktop and Server is highly recommended. Screenshots to explain the error in context are not unwarranted.

Best practice is to establish an "owner" login/schema which actually owns spatial data, and one or more  "access" logins through which the data manipulated (with access managed through roles). The account used to publish data to web clients should have the absolute minimum access possible.

I haven't ever used archiving, but I expect it would complicate the ability to drop columns.

- V