Latest Contributions by CarlBeyerhelm

OK. Thanks for the follow-up. Carl Beyerhelm – Resource Information Specialist Coconino National Forest Phone: (928) 527-3635 Cell: (928) 607-3517 E-mail: [email protected] "It is a capital mistake to theorize before one has data." - Sherlock Holmes, in Arthur Conan Doyle's Scandal In Bohemia ... View more

So far as I know, Collector does not support "smart form" functionality like calculations, conditional lookups, and so on.  ESRI's Survey123 does support smart form functionality, but it is form-centric...not map-centric...and does not support edit of existing data. ... View more

Yes, maintaining geoprocessing history can be one source of MXD bloat.  However, the most puzzling (and annoying) one is when you open an MXD, do nothing except click SAVE, exit ArcMap, and notice that the MXD has doubled in size. ... View more

Thank you... ... View more

Thank you.  That is interesting.  I hadn't explored the nuances of saving down to prior versions.  So, yes, it does seem like a bug if saving down to prior versions from arcpy results in smaller file size, but saving from arcpy to the current version does not reduce file size. ... View more

Thanks for the suggestion.  This approach does represent a solution, though not quite what I had hoped for.  It's shortcomings are that it is very slow because DocDefragmenter has to be re-executed for every MXD in mxdList (about 4.5 minutes to process 37 MXDs vs 8 seconds using the native DocDefragmenter executable), and the command line form of DocDefragmenter does not accommodate the same range of options available in the native DocDefragmenter dialog.  Nevertheless, it is adequate for situations where a scripted, non-interactive MXD file size reduction is required.  Otherwise, just running the native DocDefragmenter executable would be faster, and offers more options. Here is the working snippet that I tested... import arcpy, subprocess docDefrag = r"C:\Program Files (x86)\ArcGIS\Desktop10.1\Tools\DocDefragmenter.exe" inFolder  = r"C:\Workspace\projects" outFolder = r"C:\Workspace\projects\backups\BackUp1" arcpy.env.workspace = inFolder mxdList = arcpy.ListFiles("*.mxd") for mxd in mxdList:     inMXD  = inFolder  + "\\" + mxd     outMXD = outFolder + "\\" + mxd[:-4] + "_Defrag.mxd"     argList = []     argList.append(docDefrag)     argList.append(inMXD)     argList.append(outMXD)     subprocess.call(argList) ... View more

Hi Micheal. No specific time frame was given for fixing the issue, but ESRI did confirm that the bug persists through versions 10.2 and 10.2.1, and that a member of their development team has taken the issue on. Although lyr.replaceDataSource() would work, I elected to use mapDoc.findAndReplaceWorkspaces() as it is faster than iterating through each TOC layer. ... View more

For information, this issue has now been registered as a bug with this reference: NIM098396: arcpy.mapping.replaceWorkspaces will break the data source connection to an Image Service Layer when replacing a workspace in a map document.  Occurs with SDE workspaces, file geodatabases, and shapefiles. ... View more

Yes, the replaceDataSource() method does seem like the only ArcPy work-around at this point. Thank you. ... View more

Your suggestion would be a good approach in a situation where we needed to update the Image Service layer sources.  In this situation, however, I only need to update the SDE connections to accommodate the upgraded SDE environment.  The Image Service environment is not changing, so there is no need or desire to update Image Server layers. To illustrate this issue further, the 3 attached images document the step-by-step results at crucial points in the replaceWorkspaces() process using the ArcMap Python interactive window. The first image is from just after the layers have been interrogated for their workspacePath and a TOC refresh.  No signs of any trouble yet.  All is well. The second image is from just 2 commands later�?�the replaceWorkspaces() and the TOC refresh commands.  Here, the targeted SDE workspace has indeed been replaced successfully, but the replaceWorkspaces() method has also caused the non-target Image Sever Source properties to be deleted or corrupted.  Clearly, something in the replaceWorkspaces() method has stepped on the Image Server content even though replaceWorkspaces() did not pertain to any Image Service layers. The third image follows mapDoc.save(), and illustrates that the broken doc cannot be saved. The bottom line is that replaceWorkspaces() successfully updates the intended target SDE connections, but it also has the unintended consequence of deleting or corrupting non-target Image Service source properties. If I've missed your point, please reply back... ... View more