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; } } }

Using arcpy.mapping to change the datasource for .mxd?

DarylHochhalter

I have successfully changed the data sources for the map documents (.mxd) files, but find that when I open the mxd it puts a lock on both the old and new file GDB. I can't find anything in the updated mxd that references the old file GDB but there must be something left.

import arcpy
CurFldr = r'\\Gis Server Data\Replicas\test' + '\\'
OldGDB = arcpy.GetParameterAsText(0)
NewGDB = arcpy.GetParameterAsText(1)
mxd = arcpy.mapping.MapDocument(r'\\Gis Server Data\Replicas\test\test.mxd')
mxd.findAndReplaceWorkspacePaths(CurFldr + OldGDB, CurFldr + NewGDB)
mxd.saveACopy(r'\\Gis Server Data\Replicas\test\Copy_of_test.mxd')
del mxd

I have also tried mxd.replaceWorkspaces & mxd.save()

Using the buildt-in set datasource tool seems to work fine on the same mxd files.

Any ideas would be appreciated.

Vind meer berichten getagd met

Accepted answers

DarylHochhalter

That is indeed the issue, using False for the validate parameter is a must, if you don't the resulting mxd still references the the original datasource in some way. I just ran it both ways twice and got the same results.

import arcpy
CurFldr = r'\\Gis Server Data\Replicas\test' + '\\'
OldGDB = arcpy.GetParameterAsText(0)
NewGDB = arcpy.GetParameterAsText(1)
mxd = arcpy.mapping.MapDocument(r'\\Gis Server Data\Replicas\test\test.mxd')
mxd.findAndReplaceWorkspacePaths(CurFldr + OldGDB, CurFldr + NewGDB, False)
mxd.saveACopy(r'\\Gis Server Data\Replicas\test\Copy_of_test.mxd')
del mxd

All comments

DarylHochhalter

import arcpy
CurFldr = r'\\Gis Server Data\Replicas\test' + '\\'
OldGDB = arcpy.GetParameterAsText(0)
NewGDB = arcpy.GetParameterAsText(1)
mxd = arcpy.mapping.MapDocument(r'\\Gis Server Data\Replicas\test\test.mxd')
mxd.findAndReplaceWorkspacePaths(CurFldr + OldGDB, CurFldr + NewGDB, False)
mxd.saveACopy(r'\\Gis Server Data\Replicas\test\Copy_of_test.mxd')
del mxd

DarylHochhalter

If I close the arcmap, both locks go away. If I reopen the mxd, both locks reappear, so yes for some reason the script is keeping some reference to the datasource in the original mxd even though all the layers now reference the new datasource.

It is something in the script, because if I use the built-in set datasource tool to change the source and save a copy from the same original mxd, the problem with the locks in both File GDB's isn't there when I reopen the resulting mxd.

I'm working on it right now, and may have just found the fix, need to test one more time. The mxd.findAndReplaceWorkspacePaths call uses true for the default validate input. I just ran it adding False and it appears to have solved the issue, but going to repeat that one more time.

DanPatterson_Retired

Daryl, I saw the del, but the only way it appears that you are going to get rid of the lock is to get rid of the lock in the original. There must be something... but it may lie with where your project and data are located. On a local drive with full administrative rights, there are ways to remove the lock files

DarylHochhalter

Thanks for the input, I do use the del mxd at the end of the script. The lock I'm referring to appears in both the original and new datasource ( both File GDB's) whenever you re-open the new mxd created by the saveACopy or same thing happens if I use just save().

DanPatterson_Retired

strange according to mapdocument-class

The variable that references the MapDocument object will place a lock on the map document file. It is good practice to remove the Map Document object reference using the Python del command at the end of a script or within a try/except statement.

But find and replace approaches as outlined in updating and fixing datasources don't mention locks.

Perhaps the lock exists in the source and is being persisted in the copy.

But then again you are on .... r'\\Gis Server Data\Replicas\test\test.mxd ... which pretty well rules out a normal folder/file relationship. Sadly copying the project and the data to a local drive to fix the issue would be a long way around to fix the problem

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

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