I'm having trouble moving feature classes from one dataset to another in an Enterprise Geodatabase, despite the fact that we are not currently using versioning, the Enterprise geodatabase has been compressed, and the feature datasets have the same spatial reference.
I have to move the feature class to a file geodatabase, delete it from the Enterprise Geodatabase, and then import it. When I tried talking with Esri support, this was their solution, but honestly it seems like there has to be a better way to do this.
What methods have you tried? If Copy/Paste has failed try right-clicking the feature dataset and then Import > Feature Classes and point it to the feature class that you want to import. Often this will work for me when other methods fail.
Copy/Paste and Import>Feature Class won't work because the Feature Class already is in the Enterprise Geodatabase, just not in the right feature dataset.
Apologies, I must have been doing that in a FGDB then...
Suspect the issue is not being able to have two FC's in the same database with the same name regardless of them being in a Feature Dataset or not.
So, would probably have to do as ESRI suggests, go to different database, delete, copy back. Or, script it so that it changes the name, copies, deletes and renames.
R_
Alicia --
The RDBMS (or file geodatabase handler) is not aware of feature datasets, so even though you see it "in" a feature dataset, it isn't really, and you can't have duplicate-named feature classes, so you can't do a straight copy.
I just drag the feature class out of the feature dataset to be standalone, then drag it back in to a different feature dataset, but I just tested, and it's possible to just drag from dataset1 to dataset2 without copy. So long as the Spatial Reference is the same, it's no big deal. If the spatial references are different, then you have to rename to "_old" then use FeatureClassToFeatureClass to change the SpatialReference.
But you might want to re-evaluate whether you need to have feature classes in a feature dataset at all. If they're not being used for "feature-dataset-ish" tasks like topologies, then having more standalone feature classes would reduce the overhead of locking all the feature dataset members whenever a lock is placed on any feature class in the dataset.
- V
For some reason I thought the geodatabase would just name the copy *featureclassname*_1
Then you could just delete the original and rename the copy. But maybe that is only in certain instances.
Copy/delete/rename is far from the most efficient methodology here. I have tables with tens of millions of rows in them; doing this would cost me hours and could result in tables with columns slightly different from the datatypes I originally declared them to be. I pretty much avoid Copy for this reason.
- V