I have a file geodatabase. I am using Python to manipulate data. I have a bunch of feature classes in the root of the FGDB. What I need to do is to loop through them and move all of them into a 'Sewers' Dataset. I am able to do so by using ArcCatalog but haven't found a way to programatically to so. The following script generates error:

'Manhole' Feature Class already exists.

fd = "Sewers"
for fc in featureclasses:
  • 3
    Catalog is working because it is adding "_1" to the FC name. You cannot duplicate a FC name anywhere in the gdb.
    – klewis
    Apr 4, 2019 at 15:09
  • Oh I see. I think then I should try a different approach. Thanks! Apr 4, 2019 at 15:21
  • 2
    Actually, no. In ArcCatalog, by dragging and dropping a Feature Class from the root of the GDB into a Feature Dataset the original name is retained--and no "_1" is added to the name of the Feature Class. So there must be some way to do similar using Python. Apr 4, 2019 at 17:33

3 Answers 3


Instead of CopyFeatures_management, use FeatureClassToGeodatabase_conversion (per this thread: https://community.esri.com/thread/209420-arcpy-move-feature-class-into-feature-dataset).

Pro reference: https://pro.arcgis.com/en/pro-app/tool-reference/conversion/feature-class-to-geodatabase.htm

Desktop reference: http://desktop.arcgis.com/en/arcmap/10.3/tools/conversion-toolbox/feature-class-to-geodatabase.htm

If the name already exists in the output geodatabase, a number will be appended to the end to make the feature class name unique (for example, rivers_1).

You can also control the name of the input feature class manually.

Once you have confirmed the dataset has been imported into the desired feature dataset, you can then remove the original feature class if desired through Delete_management.

  • Thank you. Will give it a try. Problem is that I want to retain the Relationship Classes and they complain when I delete the Feature Classes. Currently, I am in the middle of creating an intermediate database to hold the Relationship Classes to be copied over--not sure if that s going to work. Thanks. Apr 4, 2019 at 18:33
  • This may be worth a new question or search of the topic here (how to retain / maintain relationship classes when datasource changes). Unfortunately not something I've encountered yet.
    – SMiller
    Apr 4, 2019 at 19:53
  • 1
    According to desktop.arcgis.com/en/arcmap/10.3/manage-data/geodatabases/…, copy would copy the relationship class as well; Have you tried copy while giving a new unique filename? Does this have the same issue with RC's when deleted?
    – SMiller
    Apr 4, 2019 at 19:59
  • I have deleted the Relationship Class from the target/final GDB and then, using the temp. GDB, tried copying arcpy.Copy_management (rc, target_gdb+"\\"+rc) but get an error that the RC already exists--it certainly doesn't. But your post above has given some food for thought...maybe try copying Feature Class into a blank GDB first... Apr 4, 2019 at 20:11

It sounds like you are trying to create a second feature class with the same name in the same geodatabase. Even if they are in different feature datasets this is not permitted.

  • Thank you. But if ArcCatalog allows moving then why can't this be done via Python? That is the original question--how to move. Apr 4, 2019 at 14:31
  • You are not showing enough details about your ArcCatalog workflow or a complete ArcPy code snippet to be certain but I suspect you are not doing the same thing successfully one way and not the other.
    – PolyGeo
    Apr 4, 2019 at 14:35
  • 2
    The code is quite long. The ArcCatalog workflow is just a small test to see if one can manually move a Feature Class into a Dataset by dragging and dropping; and that works. The Python code, as I mentioned, is long but basically if there is a flat structure GGDB then how to move feature classes into a Dataset programatically. Perhaps I can try some Feature Class name manipulation by copying to a newly temp named Feature Class then deleting the original one, and renaming the newly temp to the original name. I wish it were simpler though. Thank you. Apr 4, 2019 at 14:40

Here is how I ended up coming with a solution which meets our requirements. But, before that, some more info about my GDBs which were not clarified in the original Question by me. Basically, we have a backup of an AGOL GDB but in that backup there were no Datasets--everything was in the root of the FGBD that was downloaded from the AGOL site. However, the source data, which was used to publish to AGOL, did have Datasets (well, only one called 'Sewers') and we needed to have that Dataset back in the final/output GDB.

The solution in my Python script involved:

1) Making a duplicate of the AGOL database using arcpy.Copy_management(agol_src_gdb, target_gdb)

2) In the target_gdb, used one of the Feature Class' Spatial Reference to grab the factoryCode for the newly created 'Sewers' Dataset: sr = arcpy.SpatialReference(spatial_ref.factoryCode)

3) Deleted all Feature Classes from the target_gdb in a loop arcpy.Delete_management(fc)

4) Deleted all the static tables from the target_gdb in a loop: arcpy.Delete_management(target_gdb+"\\"+tbl)

5) Looping through the source AGOL database, copied all Feature Classes into the Sewers Feature Dataset: arcpy.Copy_management(fc,target_gdb+"\\"+fd+"\\"+fc)

Without step#4, there would be a bunch of duplicates of Feature Classes, Relationship Classes. Step #5 ensured that Relationship Classes and static tables which are part of the Feature Classes' Relationship Classes also make to target_gdb.

The result is not perfect because we have occasionally static tables renamed to something like 'mytable_1' and corresponding Relationship Classes renamed like 'myrc_1' but the data itself is making it fine and Feature Classes' and their Alias Names are matching those of the ArcGIS Online.

I don't know why we have objects like 'mytable_1' but my guess is there are objects in the source AGOL database with shared names, such as the same name for a Feature Class and a Relationship Class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.