project_service_aprx_object.save() Error from Pro 2.8.x to 2.9 upgrade

[Min-DongChang]

I have a code that a developer created that no long works for me.  With a recent upgrade from 2.8.x to 2.9, the script no errors out at a line " project_service_aprx_object.save()".  What I believe the code is trying to do update the source of feature layers in a map ("1_Service_Status_On").  However, when it comes to the  project_service_aprx_object.save() line, it gives me the following error:

Traceback (most recent call last):
File "<string>", line 686, in <module>
File "A:\Program Files\ArcGIS\Pro\Resources\ArcPy\arcpy\_mp.py", line 285, in save
return convertArcObjectToPythonObject(self._arc_object.save(*gp_fixargs((), True)))
OSError: G:\SDE_User_Connections\Projects\UnitedStates\US_Test01\Web_Services\Test01_Project_Services.aprx

I'm running the code in an empty APRX file so I don't even have the Test01_Project_Services.aprx open.  I'm a novice at python so any I can provide more of the code if necessary.

[JoeLemeris]

Following up from my previous response to a post in this thread: a bug has been created for this issue, i received a notification a few weeks ago: in addition to adding the del statement they suggest, we found success just using aprx.saveACopy() instead of aprx.save().

BUG-000145915 - An OSError message is returned when using the ArcGIS Pro project's Save function in the Python window.

Current Information:

Status: Known Limit.

Public Explanation: This is a read/only issue. They reference project A, saveACopy to Project B, then try to reference Project B and save. BUT project B is already "open" in memory.

https://support.esri.com/en/bugs/nimbus/QlVHLTAwMDE0NTkxNQ==

By adding the "del aprx_template" statement below, I believe the issue is addressed.

Workaround: Add the 'del aprx_template' statement.

[KevindeSouza]

How do you handle to copies of the project you are saving? I have a script that is using save() frequently throughout - changing it to saveACopy() results in the a read only project being written over and over again. Any advice?

[Anonymous User]

I have the same issue and have been using saveACopy() as a workaround for now. 

[JustinReynolds]

Seeing this as well in a GP tool.  After updating some layout elements we save the aprx.  Getting an OSError as reported above 2.9.2 and persists in 2.9.3 (also no relevant bug fix listed in the release notes for 2.9.3).

[codergrl]

Ran into the same issue in 2.9. It's happening because you still have a reference to the object. Make sure to call del aprx every time you're done with the object so it gets garbage collected. And this is also why saveACopy works because you get a new reference to a new object. With a lot of calls to saveACopy, you can run into a memory leak issue. See code below for example:

# this works fine
for i in range(3):
    aprx = arcpy.mp.ArcGISProject(PRO_PROJECT_PATH)
    aprx.save()
    del aprx

# this fails after the first run
for i in range(3):
    aprx = arcpy.mp.ArcGISProject(PRO_PROJECT_PATH)
    aprx.save()

Please mark as resolved if this solves your problem. 

[ThomasBaconlol]

I noticed that save functions without indentation were throwing the error for me and that save functions inside  of a loop were not always throwing an error after reading your comment. 

I chained two scripts together however and then it threw the error again so now I'm really stumped. 

saveACopy does not work for my purposes either just as a note for anyone reading.

[MichaelMorisette]

I've ran into this bug after upgrading from 2.8.x to 2.9.x.  Using the saveACopy(aprxPath) workaround worked for me as well.

[Anonymous User]

This is still present in 3.x. Note if you have any references to objects in the project you will get this error. So you may also need to cleanup any references to maps, layouts, etc. Not only the project object.

[PeterMilenkovic]

Thanks for the tip, this worked for me

I thought deleting the aprx would be enough... i had to delete the elements and layouts as well.

[anonymous_geographer]

I was encountering the same issue. However, all solutions above did not work for me. Turns out, my issue was that I had somehow corrupted my .aprx project file through previous (and albeit numerous!) script test cycles. Once I deleted the corrupted .aprx and replaced that file with a backup copy of itself, the script proceeded to save the .aprx as expected.