Select to view content in your preferred language

MapDocument saveACopy to previous version

5566
17
03-29-2010 10:49 AM
SeanFadum
Deactivated User
Hi,

I have written a small python script to save the ArcGIS 9.4 files I have created back to version 9.3.

The script seems to run fine, but when I try to open the files in Arc 9.3 I get an error message saying the files have been created in a newer version of ArcGIS.  In the help it says if you do not specify a version number that it defaults to an Arc 9.4 file.  Has anyone had success doing this, or is this a bug, or (most likely) am I doing something wrong.  Here is the script:

import arcpy
from arcpy import env
import os
import arcpy.mapping as MAP

env.workspace = "U:\\Projects_VAN\\1961\\0245\\17\\D-Drafting-Design-Analysis\\GIS\\Projects\\mxds"

for file in arcpy.ListFiles("*.mxd"):
   
    mxdFile = os.path.splitext(file)[0] + ".mxd" 

    MXD = MAP.MapDocument("U:\\Projects_VAN\\1961\\0245\\17\\D-Drafting-Design-Analysis\\GIS\\Projects\\mxds\\" + mxdFile)

    MXD.saveACopy("U:\\Projects_VAN\\1961\\0245\\17\\D-Drafting-Design-Analysis\\GIS\\Projects\\mxds\\93\\" + os.path.splitext(file)[0] + "_V_9_3.mxd", '93')
       
print "Files Saved"

Thanks in advance for your help...
0 Kudos
17 Replies
JeffBarrette
Esri Regular Contributor
I forgot to ask, does this happen using the User Interface.  Can you successfully save the map document out to a previous user using the File-->SaveACopy... command?

Thanks again,
Jeff
0 Kudos
StevenCyphers
New Contributor
Hi Jeff,

Am having similar issue with a script form of: saveACopy (file_name, {version}) in a final release version of 10.

File>save a copy {set to 9.3} > provide name.mxd works fine

via a toolbox script
with param properties set as Mapdocuments input and output

mxdIn  = arcpy.GetParameterAsText(0)
mxdOut = arcpy.GetParameterAsText(1)
ver = '9.3'

try:
    mxd = arcpy.mapping.MapDocument(mxdIn)
    mxd.saveACopy(mxdOut, ver)
    del mxdIn, mxdOut

spits out a v10 .mxd

have tried it with '93', '9.3', "9.3", str(ver)

i went as far as editing the _mapping.py
def saveACopy(self, file_name, version='9.2'):

which is when  i noticed there is no return statement in ESRI's
def saveACopy():...
in _mapping.py
is this an oversight?

fyi putting A return in  = same effect
putting '9.2' as the default value = same effect (yes got rid of the _mapping.pyc)

maybe its in the constant class assignment?
# For version
        'version': {
            '10.0': 10,
            '8.3': 83,
            '9.2': 92,
            '9.0': 90,
            '9.3': 93
        },

But it is beyond me, pls help
I really need to be able to script this, there is no way I'm going to do quantities of rollbacks via mouse clicking.

-Steve
0 Kudos
JeffBarrette
Esri Regular Contributor
We have confirmed that this is a bug for 10.0 final (and too late to fix for SP1).

SaveACopy does appear to work with CURRENT but NOT with stand-alone scripts/script tools.

mxd = arcpy.mapping.MapDocument("current")
mxd.saveACopy(r"C:\path\someNew.mxd", "9.3")

If you are experiencing this issue, please call techincal support and have your name associated with NIM061274.  It will help with expediting a fix for the issue.

Jeff
0 Kudos
GerryGabrisch
Frequent Contributor
Having suffered enough frustrations with 10 bugs and crashes, I decided to finally reinstall 9.3.1 throughout our department.  Since we have many mxds as 10 mxds I thought I could write a nice little script to convert them all to 9.3.1 mxds and get on with work using 9.3.1.  Unfortunately, I too, get the �??this map created in a later version of ArcGIS�?? message.  Too bad this function, like so much of 10, did nothing but waste my time.
Maybe, if this method works sp2, and someone is still tired of 10, here is the code to convert all the v10 mxd to 9.3 mxds in a new directory.
[HTML]
#Convert all the v10 mxds in TheFolder, and any subdirectory in TheFolder, to
#an earlier version of mxd to CopyToHere directory.

try: 
    import arcpy, os, sys
    TheFolder = r"Z:\GISpublic\GerryG\ATLAS\Copyof2010LummiAtlas"
    CopyToHere = r"Z:\GISpublic\GerryG\ATLAS\Copyof2010LummiAtlas\93mxds\\"
    for root, dirs, files in os.walk(TheFolder):
        for file in files:
            if file.endswith("mxd") or file.endswith("MXD"):
                print root
                print file
                mxd = arcpy.mapping.MapDocument(root + "\\"+ file)
                #Only make copies of mxd that have a dateSaved value (v10 only)
                if mxd.dateSaved:
                    print mxd.dateSaved
                    mxd.saveACopy(CopyToHere + file, "9.3")
    print "Done!"
    sys.exit()
except:
    print arcpy.GetMessages(2)
    print ErrorDesc.message
    print "Error"
    sys.exit()[/HTML]
0 Kudos
MalcolmParnell2
Deactivated User
We have confirmed that this is a bug for 10.0 final (and too late to fix for SP1). 

SaveACopy does appear to work with CURRENT but NOT with stand-alone scripts/script tools. 

mxd = arcpy.mapping.MapDocument("current") 
mxd.saveACopy(r"C:\path\someNew.mxd", "9.3") 

If you are experiencing this issue, please call techincal support and have your name associated with   NIM061274. It will help with expediting a fix for the issue. 

Jeff


And from here and here, not important enough to fix in SP2 either?

In fact, despite not being mentioned in the Issues addressed with Service Pack 2 document, they have done something (possibly related to fixing NIM064668?). It will actually now save to a V9.3 format, however it destroys the data paths when your MXD is using relative paths. Absolute paths seem to survive.

BTW, this bug is different to NIM058666 - ArcPy Layer.saveACopy method fails when saving to the previous version. , which is addressed at SP2.
0 Kudos
JeffBarrette
Esri Regular Contributor
Let me clarify the confusion.

Unfortunately, NIM061274 was marked as a duplicate and NIM064633 is the bug being tracked internally by Esri.  This was resolved and addressed for 10.0 SP2 and does appear in the Fixed Issues list.

The other two bugs listed in the previous post (NIM064668 and NIM058666) are related issues and were both resolved for 10.0 SP2.

I need to do some more testing but it appears the previous post is suggesting that the new fix is breaking data paths for layers stored in an MXD when relative paths are turned on.  I can't reproduce.  I assume you are talking about saving an MXD.  I ran mxd.saveACopy on an MXD with relative paths, saved out a 9.3 mxd, renamed the parent folder and could still open the 9.3 mxd without broken paths.

Thank you!
Jeff
0 Kudos
MalcolmParnell2
Deactivated User
Let me clarify the confusion.

I need to do some more testing but it appears the previous post is suggesting that the new fix is breaking data paths for layers stored in an MXD when relative paths are turned on.  I can't reproduce.  I assume you are talking about saving an MXD.  I ran mxd.saveACopy on an MXD with relative paths, saved out a 9.3 mxd, renamed the parent folder and could still open the 9.3 mxd without broken paths.

Thank you!
Jeff


Jeff, you are absolutely correct; it has been fixed. I saved to another directory and, of course, the paths didn't follow.

Apologies for my mistake and consequential confusion. 😮
0 Kudos
JeffBarrette
Esri Regular Contributor
Phew!  I was a bit nervous for a moment there.

Thanks for the update!!!
Jeff
0 Kudos