topic Can't delete some SDE fields. in Geodatabase Questions

Can't delete some SDE fields.

DanaNolan — Mon, 10 Jul 2017 17:11:23 GMT

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.

Re: Can't delete some SDE fields.

George_Thompson — Mon, 10 Jul 2017 17:33:57 GMT

Who is the data owner of the table?

Re: Can't delete some SDE fields.

VinceAngelo — Mon, 10 Jul 2017 19:16:52 GMT

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

Re: Can't delete some SDE fields.

DanaNolan — Mon, 10 Jul 2017 19:38:17 GMT

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.

Re: Can't delete some SDE fields.

VinceAngelo — Mon, 10 Jul 2017 20:03:17 GMT

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