Copy data with attribute rules is duplicating referenced feature class

RickMomsen

Software: Pro 3.1, SDE 10.8

Background: We have a script that backs up our SDE to a File GDB using arcpy.FeatureClassToFeatureClass_conversion() commands for Feature Classes (FC) and arcpy.copy_management() for Feature Datasets (FD). I have also copied data manually using the same geoprocessing tools, so this is not an arcpy issue.  

Problem: After implementing Attribute Rules (AR) on FCs in the root and several FDs that reference the GPS FC, we discovered that Pro's copy processes duplicate GPS for every FD that has a FC that references GPS. To recreate the steps:

1. create new FGDB
2. copy the GPS FC into the FGDB
3. copy the FD into the new FGDB
4. result: a duplicate GPS_1 FC in the FGDB root

or

1. create new FGDB
2. copy the GPS FC into the FGDB
3. create FD shell
4. select and copy all FCs from SDE into FGDB
5. result: a duplicate GPS_1 FC in the FD

Here is an example of our data model. Attribute Rules that reference GPS exist in many of the root\FCs or FD\FCs

• SDE\FC1
• SDE\FC2
• SDE\GPS
• SDE\FD1\FC3
• SDE\FD1\FC4
• SDE\FD2\FC5
• SDE\FD2\FC6

Hopes: We are looking for a solution to copy FCs and FDs without duplicating referenced FCs.  The only option I can think of is to 1) copy everything as we currently do, 2) delete all attribute rules, 3) delete duplicated GPS_*, 4) reimport all attribute rules. However this is a massive waste of processing time.  I hope I'm simply missing a tool that works differently and can actually see the referenced data instead of duplicating it. I'd even be OK with a hacky/unsupported workaround.

Any and all suggestions are greatly appreciated.

 

RickMomsen

My Solution - I changed our backup process to export/import an XML workspace.

The problem occurs when copying 1 item at a time. The commands determine what is selected, what is related, and what needs to be copied. When it finds that item already exists in the output, it adds the _1. 

Copying all contents of a geodatabase and pasting all at once (manually in Pro) avoids this problem, but this is not an option with any of the copy or conversion commands. The only programmable method I could find was to export the entire geodatabase as an XML workspace.  (as a pure backup I would stop with the XML backup, but our workflow needs a .gdb available for distribution).