Copy_management brings along Relationship Classes and Tables

[RandyKreuziger]

We recently added a relationaip class between a feature class and a table at the request of a user.  Now we have a bunch of python scripts failing due to how the Copy_management tool works.  The tool copies over any tables that are involved in relationship classes.   

This is great functionality but is there any way to ignore relationship classes and related tables?

[WilliamCraft]

This behavior is by design.  One way to avoid the copying of relationship classes and related tables is to use Feature Class to Feature Class geoprocessing tool.  This tool should only copy the input feature class to the specified destination, ignoring the related objects.  I believe the Feature Class to Geodatabase tool also achieves this behavior.  If you use either of these tools, however, I believe the OBJECTIDs in your source will not be the same in your destination.

[RussellBrennan]

William's answer is correct. We use the same codepath with Copy_management as we do with right-click 'Copy' - right click 'Paste' (or control+C, control+V). This maintains things like domains/relationships etc, it is actually making a copy of the data and its other related data and pasting it. Feature class to feature class is essentially an export of the data. This only copies what you specify in the tool. Copy preserves geodatabase maintained values such as OID or GlobalID while exporting data will not maintain these values.