nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Insufficient Permissions on feature B when trying to save edits to feature A

ChrisGaylor

We are having a unique issue with ArcGIS Pro 3.5.5 for 2 users. The user tries to edit Feature A but when attempting to save edits, they receive and alert that says 'Save edits failed. Insufficient permissions [Insufficient priviledges to table Feature B The current user lacks full access to table.]. We have also opened a completely new project with only Feature A in the project and receive the same message. The user does have SELECT on Feature B, but can not be given update, insert, or delete on that to protect the data. A coworker opened a support ticket with ESRI, but the suggestion was to give the users full permissions on Feature B which can't happen.

Uninstalling and reinstalling Pro fixes the issue for a while, but it comes back. If we upgrade the users to 3.6, the issue comes back in that version as well. We also tried doing the ArcGIS Pro 'soft reset' (renaming the ArcGISPro folders in AppData and reopening Pro) but that doesn't fix anything. Feature A has no relationships that involve Feature B and the 2 features aren't related in any way. This is an Enterprise geodatabase (ArcGIS Server v.11.4.0 and geodatabase version 3.4.3 - 11.4.0.55405). The feature class is traditional versioned with move edits to base, but we do not use versioning at all currently.

I should also add that we setup a test VM with the same version of ArcGIS Pro and had both users sign in and attempt to edit feature A there. Both worked without the error message so it makes me think that it's not a database issue but something happening on these users machines.

Does anyone have any other suggestions or ideas as to how we can fix this?

Finde mehr Beiträge mit dem Tag

Geodatabase

Accepted answers

ChrisGaylor

We got this fixed partially based off of your suggestion. The traditional version with move edits to base was enabled on all the features in the dataset containing Feature B. However, I removed and reapplied just to make sure something wasn't going on behind the scenes. I was prompted that there were pending edits on a version of Feature B. I checked the versions and there were none and checked with the user who edits those and she had no versions open. It gave me the option to just remove the pending edits which we did. After that, a re-applied the versioning and the issue was resolved. So, somehow I think a version got created, edited, NOT saved and then the version was corrupt or deleted somehow causing an inconsistency. Glad this is fixed. Has definitely been a hard one to crack!

All comments

Laura

I had this issue with my SQL database as well. It happened when I created new tables or features in the database. Then when my editors went to update a totally different layer they got that error. I never came up with the reason why that happens but giving them 'select' permissions on the new layer has fixed the error every time. They should refresh their connection after this is done. (we don't version either)

RhettZufelt

just ran into this issue the other day myself, but with ArcMap.

In my case, somehow (suspect because I tried to use Pro's versioning manager at some point) the traditional versioning move edits to base was no longer applied to all the tables in the FeatureDataset (or in this case, at the root level). Always seem to have issues whether or not Pro will actually change the traditional versioning or not, or mess it up.

So, opened good old reliable ArcCatalog, selected Table B and un/re-registered with move edits to base.

Next edit attempt on Table A give save error, but for Table C. Used Catalog to re-register Table C with move edits to base and all is happy now.

Most of my data that has versioning move edits to base are in Feature Datasets, so this usually isn't an issue.

But, it appeared as if all the tables in root behave as if in a Feature Dataset except each table has to be versioned separately.

Not sure if this applies to your case, but checking that all the FC's/tables in the level of Table A to make sure the versioning is the same might help resolve it.

ChrisGaylor

Both of the users already had select, so this didn't seem to be the issue in our case.

ChrisGaylor

George_Thompson

Did you happen to add a new feature class to the feature dataset that was already versioned?

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.