Detecting Corrupt MXDs in Python

3056
13
Jump to solution
04-09-2012 08:36 PM
JanetRogers
Occasional Contributor II
I have a python script that loops through all the MXDs in folder and subfolders and writes details of the layers to a text file.  The script works quite well, unless an MXD is corrupt at which point it fails (which I can completely understand!).   The corrupt MXD caused ArcGIS to crash when I tried to open the document in ArcMap and also when I attempted to preview it in ArcCatalog.  I am not sure if it can be done, however can anyone suggest a way to check the MXD before making an attempt to process it by the script.
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
MichaelVolz
Esteemed Contributor
Janet:

I have had to perform this task in older versions of ArcMap as well where python did not have its current capabilities so VBA was used.  In each case, whether it be in python or VBA, a corrupt mxd always crashed the script even with error handling such as try...except was used.  I have spoken with ESRI Technical representatives and they have confirmed that there is no way around a corrupt mxd in VBA or python scripting except to exclude it all together from your loop.

In my case, I had a script that would take an inventory of all mxds and various connections such as SDE.  This was a read-only step where information was saved to an output text file.  When the script would crash on a corrupt mxd, it would be noted and added to the code for the other script, that modified paths to data, so that script would just bypass these corrupt files and hopefully never crash.

I hope this information helps you to come up with a solution.

View solution in original post

13 Replies
AndrewChapkowski
Esri Regular Contributor
Have you tried putting a try/except in your code to catch the map documents that are causing you issues?

.... in loop
[INDENT]try:
    mxd = mapping.MapDocument(mxdPath)
    #.... do something
except:
    #write to file which map documents are incorrect[/INDENT]


The try/except pattern should allow you to ignore the errors and output the failing paths to a text file or something else.  You can then take that file and run the mxd doctor on them.
0 Kudos
JanetRogers
Occasional Contributor II
Thanks for your suggestion.  I am already using Try... Except, however the whole thing crashes before it gets to the exception handler.  I don't think it is possible to get around this - just wondered if there was some way of looking at a whole MXD to see if it is corrupt without actually going into it. Sort of like some Excel functions such as ISNA.
0 Kudos
AndrewChapkowski
Esri Regular Contributor
Do you know where it's crashing?  Are you sure it's related to arcpy/a bad map document?

Can you post a sample of your code and a good and bad map document?
0 Kudos
JanetRogers
Occasional Contributor II
I apologise for taking so long to reply.  Been so busy I haven't been able to get back to this script.  I deleted the MXD that caused the problem, as it couldn't be opened either so I can't get post it here.  When I get a moment free I will see if I can replicate the problem somewhere else.

I'll attach the code so far.  (Realised I need to check for broken data sources before I write out the layer details, so coding is still not complete).
0 Kudos
MichaelVolz
Esteemed Contributor
Janet:

I have had to perform this task in older versions of ArcMap as well where python did not have its current capabilities so VBA was used.  In each case, whether it be in python or VBA, a corrupt mxd always crashed the script even with error handling such as try...except was used.  I have spoken with ESRI Technical representatives and they have confirmed that there is no way around a corrupt mxd in VBA or python scripting except to exclude it all together from your loop.

In my case, I had a script that would take an inventory of all mxds and various connections such as SDE.  This was a read-only step where information was saved to an output text file.  When the script would crash on a corrupt mxd, it would be noted and added to the code for the other script, that modified paths to data, so that script would just bypass these corrupt files and hopefully never crash.

I hope this information helps you to come up with a solution.
KariBuckvold
Occasional Contributor

Michael,

Can you share how you noted when an mxd was corrupt?  I'm also working on a program that walks through mxds in a folder to determine if a particular layer is used or not and writes it to a csv file but the script crashes when it encounters a corrupt mxd.  But it crashes before the list is written to the csv file so I never know which one it is.

Any guidance would be great

0 Kudos
MichaelVolz
Esteemed Contributor

Kari:

Although this adds another step to your process, I would run through the files that you plan to process without actually resourcing your data and log the files that you have read through.  If the script crashes, you know it is the next file in the directory so you can exclude that file by name (or delete it entirely if you find it totally corrupted).  I would perform this process by subfolders of your main folder so if the script crashes on a corrupt mxd you don't need to go through as many files in your next run.  This was an important step in resourcing my organization's mxds and lyr files which numbered in the 10s of thousands and had 100s of thousands of data connections that needed to be resourced.  I hope this information helps you through this tedious but important process to your endusers.

AndrewQuee
Occasional Contributor III

Good point Michael.  Michael Volz

As we've had a couple of issues like this as well, we tend to use this method a lot now for each operation:

with open(path + 'Log_' + Date + '.log', 'a') as output: #open log file in append mode.

        output.write(logentry)

output.close()

Although this slows down the process quite a bit, it's better to know exactly what happened and at what point rather than the script simply crashing and not flushing the output cache to file.

Edit: Added code format style to snippet, for some reason it wouldn't let me choose this when wrote my reply.

KariannBuckvold
New Contributor II

"append" was the key I was missing!  Thanks, it's always the little things!

0 Kudos