Remove [Read Only] .aprx lock when the original file is closed

wayfaringrob

I just made a bunch of edits to a file that I didn't realize I had open twice. I was making my changes in the [Read Only] instance. I closed the original, but still cannot save. I get an error when I try to overwrite. [Read Only] still appears at the top despite this instance being the only place the file is open. It seems I'm going to lose my work, or have to save as a new project, which I'd like to avoid. This would also come in handy when multiple people have the same project open.

RandyCasey · ‎12-06-2021

I too have had this pain. If you have the Python skills, saving the edited features into a separate feature class and using Search Cursor/Update Cursor combo to find and update matching features is about the only way to avoid manually digitizing.

This shouldn't still be a thing. Years ago (before O365) Microsoft Office products would tell you when you were in a Read Only session and offer you the option to be notified when the current edited version was closed so you could transition into an edit session without losing your work. It would be really nice if esri would look into this as an option.

wayfaringrob · ‎12-06-2021

@RandyCasey, oy. I wound up deleting my changes and re-doing the work, but I wasn't happy about it. I should have said edits to symbology and layout - I wasn't editing any feature classes. But yes, even Office products do this, and other Esri files such as feature classes are 'smart' about their locks in this way.

KoryKramer · ‎12-06-2021

I'm sorry that you had to re-do work. As a workaround, couldn't you use the Save As a new project option that you mentioned in the idea's opening description?

Save the copy into the original project's same folder with project_new. Then either delete the first project (or rename that project_old) and update the copy's name to project.aprx.

For example, here is the project copy after I've deleted the original (outdated) aprx.

After removing _new I have the original structure and naming and have kept any changes that were made in the Read-Only copy rather than having to re-do those.

The idea is valid, but I wanted to share this as a workaround that might help.

wayfaringrob · ‎12-06-2021

@KoryKramer I'll have to remember that workaround for next time (though I'm hoping I don't have a next time!). If I were using ArcMap, I would have that without question. The structure of a Pro project, files and all (and my lack of knowledge about all the nuts and bolts), had me scared that that would break something. In other words, I didn't know that was possible without a total renaming/reconnecting.

Michele · ‎03-13-2023

@KoryKrameryour workaround is what I have been doing, but it would be better if either a pop up comes up when you initially open a project that is already open somewhere else telling you it's read only (or at least the option for the pop up to be on or off in the options menu). It is missed many times in the top bar. Once the person who has the editing version closes it, the read only version should become editable. If multiple people have read only versions open, the software should keep track of the order in which it was opened (by pc name or such) and release the lock on saving to the original file in that order. I've found many versions of the same project that people don't go back and delete (laziness) because of this. Bad data management practices.

KoryKramer · ‎03-13-2023

@Michele for your use case, where it sounds like multiple people are purposely opening the same shared project, and purposely needing to make changes to and save to the same shared project, keep an eye out for Portal Projects in an upcoming release: https://community.esri.com/t5/arcgis-pro-documents/arcgis-pro-roadmap-february-2023/ta-p/1261591

Michele · ‎03-13-2023

@KoryKrameroooh. sounds interesting. A lot of times multiple people just have it open, but because of corruption issues in ArcMap we are very careful about editing anything if we know the mxd is in use for production. Most of the time the other people in the same project/mxd just need to see something. The ability to have multiple people editing in the same project at the same time would be amazing!! We could split up the workload and get it done faster, if that's where Portals Projects is heading? There doesn't seem to be much details on it yet.

KoryKramer · ‎03-13-2023

>>The ability to have multiple people editing in the same project at the same time would be amazing!! We could split up the workload and get it done faster, if that's where Portals Projects is heading?

Yes, that is where portal projects is heading. The main project will reside in the organization's portal (ArcGIS Online or Enterprise) and when a user begins to work, it will download a local copy where they will make their changes - update a map, add a layout, add project items like folder connections, etc.

Another user or users could do the same. When a user saves, it syncs their changes up to the portal project and also receives any changes from the portal project down into their local version. In this way, multiple people can be working in the same project at the same time, and there will be basic conflict resolution - but it will likely work best if, as you indicate, a workload is purposefully split up...

EDIT: This new functionality will first become available with ArcGIS Enterprise 11.1. We are assessing the feasibility of what can be offered through ArcGIS Online.