This worked for me. Obviously not ideal, but a workable solution. Thank you!
This error appeared when I was editing attribute data in pro. I tried re-exporting the features to a gdb and it didn't work. However, I did try something else that worked.
Close out of pro and it will prompt you to save all edits. This isn't a long term solution but it seems to be working smoothly for me now.
Ah, Compact (usually a good idea) vs Compress (need to consider your use case).
I also had encountered this problem. Didn't realise that my compressing the geodatabase made it read-only... a problem of my own making... 😞
Sounds like a possible issue with Pro's new 2.1 functionality to have metadata for a layer and feature class separately. Please consider reporting this issue to support so they can get it fixed.
SOLUTION:
In my case I was using arc pro, on a server network. Would used a FC to FC. Would then become read -only. I would right click on my new feature class>Properties>Metadata
The first box is a drop down, I chose "Layer has its own metadata"
Running 10.5.0.6491 on windows 10, saving to a network drive and I get this error. If I close down and re-open the same project there are no issues for while. any more recent solutions?
Disabling anti-virus on access scan of all FOLDERS with *.gdb resolved the issue for us
We found another cause to this issue last month:
If you use Catalog connections to the same folder mapped two different ways (ie UNC and letter drive) within your ArcGIS Desktop session, you can run into nasty access issues.
Don't do that!
We just ran into this above today. Single user (checked the lock files, yes all from the user's arcmap process), select the GDB in the ArcMap catalog window error message pops up that schema locks exist.
Here's a comment from a 2008 forum thread by Tom Sethre that I thought was helpful:
While exchanging emails with Mark S. with ESRI Support three weeks ago, I stepped through my test sequence once more. I opened ArcCatalog and tried to create a File Geodb on the network drive (in the same folder as my Personal geodb). It failed with a schema lock. Clearly nobody else on the network could have caused the schema lockout. THE CRAZY-MAKING THING: I then closed ArcCatalog, deleted the New File Geodatabase folder, re-opened ArcCatalog and was able to create a new File Geodatabase on the second try. An attempt to copy a shape from the Personal Geodb to the new network File Geodb failed with the schema lock error. MY THEORY ArcCatalog is not allowing time for its lock release to propagate through the network. It looks to me like a timing issue. I believe that ArcCatalog releases a File Geodb schema lock by deleting the lock file. Sometimes it may take a few milliseconds before the network drive can complete the file delete request and re-broadcast its revised directory contents. This would be consistent with the intermittent nature of this problem.
While exchanging emails with Mark S. with ESRI Support three weeks ago, I stepped through my test sequence once more. I opened ArcCatalog and tried to create a File Geodb on the network drive (in the same folder as my Personal geodb). It failed with a schema lock. Clearly nobody else on the network could have caused the schema lockout.
THE CRAZY-MAKING THING: I then closed ArcCatalog, deleted the New File Geodatabase folder, re-opened ArcCatalog and was able to create a new File Geodatabase on the second try. An attempt to copy a shape from the Personal Geodb to the new network File Geodb failed with the schema lock error.
MY THEORY
ArcCatalog is not allowing time for its lock release to propagate through the network. It looks to me like a timing issue.
I believe that ArcCatalog releases a File Geodb schema lock by deleting the lock file. Sometimes it may take a few milliseconds before the network drive can complete the file delete request and re-broadcast its revised directory contents. This would be consistent with the intermittent nature of this problem.
The patch for 10.1 sp1 that Sean mentions can be found below or 10.2.1 or newer release can be used that includes this fix.
ArcGIS 10.1 SP1 for (Desktop, Engine, Server) Quality Improvement Patch | Samples and Utilities
As noted above this has been fixed in 10.1 QIP and 10.2.1 as part of NIM-094612.
This issue seems to occur occasionally in 10.2 (currently running ArcMap Advanced/Catalog version 10.2.0.3384). I got the "cannot save edits" unknown error occurred" while working with a polygon feature class in a file geodatabases, I am the sole read and read/write user of the geodatabase. I was doing a lot of tracing of other features in my editing tasks, I believe the trace errors that used to be expected in 9.3 are still creeping in the shadows of 10.2. At some point while trouble shooting I got another error that said "cannot find GDB_Item" but I have no idea what that could mean.
I have not seen anyone suggest a work around, so here is something you can try so you don't loose your data next time:
The work around I found was to right click the layer I was working on and go Data>Export Data. Not sure if there is something to this or not but as my first try at this my ArcGIS froze my CAD workstation or about 5 minutes, when it came around and I finally canceled the process. Then I used Data>Export to CAD and locally saved the layer I was editing as a CAD file. Reassured that my work was somewhere retrievable and not entirely lost I did Data>Export Data again with no problems. I closed ArcGIS without saving my edits (since it would not let me save my edits) and then re-opened the .mxd.
The choice is yours whether to import the newly saved layer from the Data Export and copy/paste the edited features into the original feature class, or simply archive the original and adopt the export as your new working dataset moving forward. If you do the latter you can import the layer symbology from the original layer, that get's you right back where you were like it was just bump in the road.
Hope that helps someone.
We had this same error with editing and replication since 10.1 was released. A little known Esri Quality Improvement Patch was released earlier this year for 10.1 SP1 users and can be found here ArcGIS 10.1 SP1 for (Desktop, Engine, Server) Quality Improvement Patch | Samples and Utilities . After installing the patch we do not have the "Read Only" any longer.
Add another instance to the list. Has a solution been developed? Does a complete reinstall work?
Thanks!
UPDATE:
Load the ESRI Quality Improvement Patch for 10.1 SP1 developed this year, last updated May, 2014. It loads on top of SP1.
Recently ran into the same issue, even with my file geodatabase on a local drive (ArcGIS 10.1, Windows 7). I read this thread, did all of these things that have been suggested in this thread, and it seems to be working as it is supposed to now (able to save edits)!!!
I'll come back and edit this if the issue ever rears its ugly head again.
It worked well for about 6 hours of editing with many saves. But at the end of the day, I got the "can't save edits" bug again. So we can rule out the DropBox and Google Drive Sync as the culprits. The fix must of have come from the registry fix as my "repair geometry" earlier didn't fix any bad geometry. So, this has got to be a bug in ArcGIS's ability to write correct registry settings to the Operating System, which eventually screws with Desktop's ability to maintain a "lock" on the file geodatabase files within the file geodatabase folder.
Well, hopefully an upgrade to Windows 8 and ArcGIS Desktop 10.2 will fix this bug. It's pretty frustrating as one of the most fundamental GIS tasks is to edit data, and have the ability to save your edits. In fact, it's one of the most basic functions of any computer program, really.
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
