I have at least 15 people editing on one of our Enterprise SDE Geodatabases. I set up another user to edit and it is giving me an error I can't figure out. I set the same exact permissions as the other users who are editing fine and have been for months.

Database is SDE on SQL Server 2008, Arcgis Server 10.3, he is using ArcMap 10.3.1

Sidenote he had just got Windows 10, I think everyone else is using Windows 7.

enter image description here


With help from @john, I finally think I got it. For some odd reason with this specific user the permissions didn't take through ArcCatalog. I had to go into SQL Management Studio and add the permissions in User Mapping for the specific user. He is now able to edit.

enter image description here


May or may not be the cause of the issue you're having, but some things to check when a user is unable to edit a feature class in an Enterprise GDB they should have permissions to edit:

If new install on new OS as you note, make sure the computer has the right version of the appropriate RDBMS access client installed (ex: SQL Server Native Client) for client to connect to RDBMS.

Also, check the settings of the version being edited. If the default version is set to protected, they could see it but not edit it, even if they have permissions to edit the feature class. More info on setting version permissions is at http://desktop.arcgis.com/en/arcmap/10.3/manage-data/geodatabases/creating-versions-and-setting-permissions.htm

And a final thing to check, though perhaps you have already, is to ensure they are actually connecting to the geodatabase as the user you gave edit permissions to. If you're using the integrated windows user based authentication, then this is likely not as much of an issue, but if you have a mixed or database only authentication model, then I would just double check that the *.sde file they used to access the feature class is actually using the correct user account. For example, if they are directly using or copied another user's pre-existing *.sde file to connect to the database, they could be unintentionally connecting with a user account that does not have access, even if the user account they should be using does have access. Again, this may or may not be likely in your given situation, but it doesn't hurt to check (especially if your users save *.sde files to a shared network drive other users can access...).

And of course, as is always recommended with any ESRI software bugs in my experience, make sure you try it directly adding the feature class to a brand new MXD after having restarted the computer, just to make sure there aren't any MXD or similar corruption issues.

  • Thanks @john for the quick reply. I checked everything you said, and no avail. I reinstalled the SQL Server 2008 R2 Client to make sure. We are using windows authentication. I brought the layers into a new blank MXD through the Add Data tool and tried editing. Default version is not protected. I'm stumped.
    – GravitaZ
    Feb 6 '18 at 20:40
  • And just double checking, but it's not a new feature class you're trying to edit right? Ex: if you add a new feature class to an existing feature dataset, it will not automatically gain the permissions set to that feature dataset until you reapply the permissions in my experience... again, not saying thats it, just pulling at straws at this point. Basically, can other users edit the same exact feature class, or just others can edit other FCs in the same GDB.
    – John
    Feb 6 '18 at 21:29
  • @GravitaZ, oh, and is this issue particular to a specific feature class, all FCs in a feature dataset, or everything in the GDB.
    – John
    Feb 6 '18 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.