Select to view content in your preferred language

Export XML Workspace (flag to export like ArcMap)

03-24-2021 08:48 AM
Status: Closed
Labels (1)
New Contributor III

The tool "Export XML Workspace Document" provides a means to export SDE Enterprise Data into XML which can be imported into a file geodatabase. The tool performs differently between ArcMap and Pro.

With ArcMap I was able to run this tool on my enterprise geodatabase that contained unregistered views and the export and reimport regenerated the view data as static in the file geodatabase. It was a fantastic method to perform "static" archives of flattened data. However,

with ArcGIS Pro, the tool behaves very differently, and while it does allow all my standard SDE data and view data to be exported. The tool crashes when the xml is used for import. I reviewed the newer xml schema and it looks like the new tool perhaps rightly identified that globalid's for the exported view data are not true globalid's, etc. Anyway, the tool fails. While this might be the intended behavior of the tool (perhaps the view data would work if registered with SDE), I pine for the older ArcMap abilities and would request an idea to add a flag to the tool to "mimmic" (older xml functionality) .


If this is a bug, then please fix it. Unfortunately, this is an enterprise dataset and I am unwilling to play with registering the views at this time.


Tags (3)
Status changed to: Needs Clarification

Hi @KevinMorris2 

I apologize that you're running into a crash.  We want to help investigate and get that fixed, but ArcGIS Ideas isn't the right place to report crashes as explained in the submission guidelines.

2. No bugs please. Idea Exchanges are not the right place to log software bugs or crashes.  Keep in mind that just because it isn’t the right fit as an Idea does not mean that we aren’t here to help.  Bugs and crashes should be logged with Technical Support.  If working in ArcGIS Desktop/ArcGIS Pro, crashes can be reported by sending an error report.   

Given that, if you could please send the .dmp file of the crash that would be helpful.  Go to C:\Users\<username>\AppData\Local\ESRI\ErrorReports and attach a few of the latest .dmp files from Pro crashing.  The filename contains a date-time stamp:


Are you also able to include the .xml that causes the crash?  You can email  If we need to set up an ftp site to transfer data we can do that.  

Thank you!


At this time, both xml import tools are showing similar behavior (fail due to duplicate column name) in ArcMap and Pro. Due to this, it is suspect that the underlying issue is a duplicate column name in the custom view. I will be reviewing the custom view select statement for duplication and irregularities and convert SELECT * to defined column names if the view used this approach.

As I have used this tool for this database several times with ArcMap, it can only be assumed that versioning of the software or modification of the SQL Server Custom View is responsible.



ESRI identified my issue as a bug.

"First of all, thank you for providing all the information and data so we could test your workflow on our end. After testing this behavior, we have determined this to be a software defect. The reference number is #BUG-000139764 . Its synopsis states, "Import XML Workspace Error 001188: "Cannot create a table with a duplicate column" when using unregistered views"

This bug will now be reviewed by our development team, and they will take further actions as necessary to address this issue as soon as possible. For updates on this issue, please see the My Support portal at

The workaround for this issue in the mean time is to register the views if possible.  "

Status changed to: Closed

Closing this idea since this has been logged as a bug.  

If you are encountering the same behavior, please go to and use the Subscribe button.

Thank you.


I've needed this tool repaired for several years prior to this post and still don't see it fixed in the newer versions of ArcGIS PRO. Due to this I identified that use of OBJECTID in SDE enterprise, VIEWS was the culprit when exporting to xml workspace. I created a rudimentary python script that will create a new xml document where each instance of a custom View that contains OBJECTID is fixed. Do note that GlobalID is another attribute that you may wish to restore to a true GlobalID as ESRI xml tool modifies it to a GUID in the code (I think - I could have recast it in the view). The tool requires exporting your SDE data as Normalized.

# Version 1.0
# 6/23/2022 KM NPS
# This script was created to repair XML workspace documents created from ESRI ArcSDE using ArcGIS PRO when the enterprise has un-registered views
#   that utilize OBJECTID and GlobalID in their view fields derived from other Version View Feature Classes or Tables
# This script is designed for creating copies of data from an enterprise SDE dataset to an ESRI file geodatabase.
# Normal behavior of exporting feature classes and tables from SDE to a workstpace doc creates an xml file where OBJECTID is not considered
# for it's intended purpose. In addition globalids that may be dups from a view are also not handled as globalid, but transitioned to guids (this is ok)
# So exporting from SDE works and you can get an xml doc from ArcGIS PRO
# However, recreating the data in a new filegeodatabase crashes when using the xml workspace document.
# The issue is ONLY with sql views (and may work if they were registered, but I didn't register them)
# The minimum requirement to fix this issue is to change 3 parameters (if you are duplicating Objectid in a view)
# for each feature class or table if you use OBJECTID in your fields, then you need to make sure
#      HasOID is true (default is false for views),
#      OIDFieldName is set to your OBJECTID (default is blank for views)
#      Change Field Type for OBJECTID FROM 'esriFieldTypeint' (or similar)  to 'esriFieldTypeOID'

# Additionally, the xml parameters for GlobalID can also likely be modified to configure this field to act like a globalid in the export filegeodatabase
#   However, for my purposes, keeping record of the GlobalID as a GUID (converted by ESRI tool) works just fine for my archival purposes.
# After rewriting the document it should work.

# NOTE: It was important that lxml was used over xml library due to the standard xml library messes with the namespace and lxml maintaines it. See end of doc for example.
# NOTE: This script does not work on xml document with Storage Type: Binary. Requires Storeage Type Normalized

#import xml.etree.ElementTree, ElementInclude as ET
import sys
#from xml.etree import ElementTree, ElementInclude
from lxml import etree
xmlfile="C:\Projects\SEKIsql_HazardTreesV2_Export5.xml"  # Hardcoded file to be "fixed"
#tree = ElementTree.parse(xmlfile)
root = tree.getroot()
for DataElement in root.iter('DataElement'):
    if DataElement_HasOID.text.lower()=='false':
        for child in DataElement_Fields:

            if DataElement_Name.text.upper()=='OBJECTID':
                print('-- Modifying Schema to use OBJECTID as OID --')
if ismodified:
# Needed to add this because the xml name space parcer removed the ESRI namespace  ***NO LONGER NEED THIS AFTER transferring from xml library to lxml library that maintains namespaces
#    with open(xmlfile.split('.')[0]+'_modified.xml', "rt") as fin:
#        data =
#        data = data.replace('''<ns0:Workspace xmlns:ns0="" xmlns:xsi="">''', '''<esri:Workspace xmlns:esri='' xmlns:xsi='' xmlns:xs=''>''')
#        data = data.replace('</ns0:Workspace>','</esri:Workspace>')
 #   with open(xmlfile.split('.')[0]+'_modified.xml', "wt") as fin:
 #       fin.write(data)