Looping Through Layers in Mxd and Saving Mxd Changes Extent

[MichaelVolz]

To All Python Users:

I have a script that loops through all the layers in an mxd and then saves the mxd.  I have found that when I open up the saved mxd the extent of the map in the data view has changed even though I did not write code for the extent to change.  Has anyone come across this phenomenon before?

The problem I am finding is that the layout view, that could be setup for a print job, has changed.  Now the user has to go back and fix the extent for the layout to be printed correctly.  I am eventually looking to run this script on many mxds in batch and I do not want to disrupt all the mxds where the endusers need to go back and fix the extent.

Why would the map extent change if all I am doing is looping through the layers in a python script?

[LorindaGilbert]

I found one mxd that was using an annotation feature class, it does appear to have changed it according to the source under properties.

[MichaelVolz]

Do you need to process SDE annotation feature classes differently than standard SDE feature classes?

I think I see why my annotation feature classes are not being processed.  I bypass group layers so I only process individual layers.  In looking at the properties of an annotation feature class, it appears to be a group layer.

Do you bypass group layers in your script?

[LorindaGilbert]

I didn't put anything special into the script to look for a different type of feature class.  Here's a slightly modified copy of my script (to protect the innocent :cool: ).  I did use parts of other scripts that I found on the forums and on the resources page.  I do intent to make this script much more flexible for future use.  We have several SDE servers here, so being able to have a flexible script is a must.  Hope it helps you.

I also intend to create another script that will go through the layer files that we have saved for general use - next item on my list.

[MichaelVolz]

Lorinda:

How does your script handle group layers?

[LorindaGilbert]

Just checked my data driven pages mapbook which has groups within groups,  and it appears to have handled them like a champ and changed them to the new server.  Of course, when I turn the old database off next week, I may be eating my words 😛 .  But the source properties are showing up as I would expect if I had manually changed the data source.

[MichaelVolz]

Lorinda:

I just figured out why my script was not handling annotation feature classes.  Annotation feature classes are structured similarly to group layers and I had an If statement asking whether the focus layer was a group layer or not.  If the layer was seen as a group layer (as an annotation feature class is), the layer would not be processed.  This was faulty logic as other conditions would prevent a true group layer from being processed, but still allow an annotation feature class to be processed.

[LorindaGilbert]

Grrr...
Has anyone else run into this?
I turned off the old db last night and we attempted to run this script that I had created and NOW it doesn't change anything!  Yet it worked very well with the db on prior to this.

Have since turned the db back on and now the script works.

So warning to all that may be looking into this - make sure that it is done with both databases and servers up and running.

If someone has managed to run a python script to replace the data source with the old source off, please let me know how you did because we are likely to run into this again.

Thanks.

[MichaelVolz]

Lorinda:

How does your script handle broken datasources?  If you do not process broken datasources, then your script will never process connections to the old db if it is off while running the script.

You may also be running into an issue where python is trying to get the old SDE connection properties so it knows where to resource the connection.  Since it does not see the old connection properties when the old db is off, it does not know what to do.

I would think you would need to keep the old db around until you are certain that you have successfully processed all of your SDE connections.

[LorindaGilbert]

Michael,
I had in the original script to at least let the user know that there are broken links (we still had some mxd's from two and three servers ago!!).  It would alert the user that there was a problem with certain data and then continue on.

Once the db was turned off, ALL feature classes were broken links and it wouldn't change anything at all.

I was mainly putting the info on the forum as a warning to others to run these types of scripts before the db is turned off so that it has a better change of running properly.  With any luck, in future versions of AG and ArcPy (we are running 10.0) they will handle stuff like this better because sometimes you don't have the choice of being able to turn a db back on - especially if the server died completely and you had to move the db to another server.  You also don't always have to option of naming a server the same name.

So for now, I've turned the db back on for a few days to allow for the users to get to the directories with many mxd's (several with over 100) changed over.  Any others that are looked at later, will just have to use the repair data source option within ArcMap.

Thanks.

[MichaelVolz]

Lorinda:

How would you be able to resource a datasource whose current properties you cannot access?  I'm not sure how ESRI would help in this scenario as the parameters you need in the findAndReplaceWorkspacePath can only be accessed if your SDE layer is not broken.