I have a file geodatabase with feature classes created from shapefiles that serves as the main gdb for our web GIS. The gdb is registered with and stored on the server (single machine deployment).
I am able to edit the data without any issues. However, when my co-worker tries to start editing receives the error "No editable layers." for the gdb as a whole, and the error 'Could not edit the data in the folder or database you selected." for individual feature classes in the gdb.
I've checked and he has the proper permissions to be able to edit the gdb, and I've also made sure that no one else was accessing any feature class in the gdb when they went to start editing. In spite of this, they still get the same errors.
Could it have something to do with the versioning? I also don't think it's because the gdb feature classes are referenced on the web GIS since I'm able to edit without issues.
Does anyone have an idea of what could be causing this?
Did you check that they have write access on the server location where the file geodatabase is stored?
Also, are they trying to edit versions, or the main file geodatabase?
Yes they have write access on the server location. As far as editing goes, they are trying to edit the feature class within the main file geodatabase.
I read that the feature class that is to be edited should have editor tracking enabled, and be registered as versioned. Is this true? If so could that be the issue? I haven't done either of these since I had no issues editing the feature class previously.
I have never heard of having to register a FILE geodatabase feature class as versioned (I have heard of that for SDE feature classes) but maybe I just have never run into that because it hasn’t been my workflow..
However, I’d try to have a person who currently can’t edit do this:
In Arcmap, add the feature class…don’t try to start editing yet, but in the editor toolbar, Versioning tab, uncheck “Edit a version of the database with the ability to undo and redo” and then Uncheck “automatically save changes after each edit”
Then attempt to edit the feature class. If it is now able to be edited, then stop editing without saving, and then try registering the FC as versioned, because that is probably the problem.
Thanks for the reply Nina.
They went into Arcmap and tried this out, but they still got the same error as before.
I've seen that granting privileges on the database could be the issue as well? I've never heard of this on a file geodatabase, so i'm assuming this only applies to SDE databases?
What license level do they have? File and personal geodatabases with advanced features such as topology or relationships require a Standard or above to edit. Could that apply in your situation?
We have two advanced concurrent use licenses for our department so I don't think that is the issue. I'm about out of ideas as to what the issue could be. I went back and made sure their permissions were correct on the server, and every other thread I'm seeing about this is dealing with enterprise databases.
Does the user have multiple dataframes in the *.mxd and is attempting to start an edit session on an inactive dataframe by chance? This has come up in Support Services calls in the past.
Thank you for the idea, but I don't believe so. I made sure they opened a new .mxd and only imported the layer they were trying to edit, and they still got the same error.
I have had that happen to myself in the past though when working on a grid index! It's always a frustrating few minutes until you realize the wrong data frame is active.
Thank you for this Michael! I was spoke with a co-worker yesterday and they thought this could be the issue as well. I let our IT know about the issue so they can double check the security parameters before I open a support case.