Unregister a Feature Class

[BartPittari]

(Using ArcGIS 10.8.1 and Oracle 19c)

I'm trying to unregister some older feature class tables (legacy ESRI Binary geometry) from our geodatabase, since they all have newer ST_GEOMETRY counterparts (either as standalone or as part of a view), as a means of avoiding confusion with the end users as to which is correct.

What I'm basically trying to do is to get the (legacy) table to be viewed by Catalog as a table and no longer as a feature class.

As I've researched, post-SDE, I don't think there's a straight way to unregister something (these are unversioned), so what I was going to try and do, is run a delete on the sde owned tables and possibly also null out the shape column:

delete
from SDE.table_registry
where owner = 'myschema'
and table_name = 'myfeature';

delete
from sde.column_registry
where owner = 'myschema'
and table_name = 'myfeature';

delete
from sde.layers
where owner = 'myschema'
and table_name = 'myfeature';

delete
FROM sde.geometry_columns
WHERE f_table_schema = 'myschema'
AND f_table_name = 'myfeature';

UPDATE myschema.myfeature
SET SHAPE = NULL;

I've tried it on a test case and it still somehow shows up as a (blank) FC in Catalog, so I'm guessing that there's some place else that still recognizes it as registered. 

Is there anything else that I would need to do in addition, or instead of this route? 

[George_Thompson]

I am not sure that there is a safe (or supported) way to unregister a feature class from the geodatabase outside of deleting the "old" FC. There are lots of other tables where dependencies may live.

If you created an unregistered spatial table, it will show up as a "feature class" in Catalog, but not be able to participate in the advanced geodatabase functionality.

Based on the background above, what is the "benefit" for you to unregister?

Why not export it to a file geodatabase / change the name to something different so it does not get used?

I am trying to understand the "why" you want to do this?

Look forward to hearing from you soon!

[BartPittari]

Short answer - the client wants to keep the data on the GDB in case any end users are still using it (there's a lot of old items out there).  Part of the unregistration attempt is also to remove confusion when a user attempts to load something in ArcGIS Portal.  We want them to load the newer items, but we have "very special" end users, so anything to avoid confusion. I'd guess that the "benefit" is not getting a bunch of trouble tickets from users who don't use the system much and will easily confuse table_a with table_a_st and load the former and have it fail.

[George_Thompson]

Ok, thanks for the additional information.

If it were me, I would just rename the table to something that would not cause confusion.

Even if the table was "unregistered" it would still show up in the ArcGIS client.

[BartPittari]

The rename may be on the table as a final option (they don't like to rename or delete anything if possible), but the desire from them is to "unregister" them in such a way that they keep the name and current data, but appear as an SDE Table instead of an SDE Feature Class. 

You'd think there would be some way to unregister, lol. I'm likely going to have to run a trace and see what all else is touched when I do a delete on an FC.

[VinceAngelo]

There is no effective unregister, just geodatabase corruption.

I'd create a new table with "CREATE TABLE newname AS SELECT * FROM oldname" then use ArcPy to Delete_management() the 'oldname' feature class but I'm only ever using native geometry types. SDEBINARY are not effectively recoverable from *either* the DELETE FROM sde.* hack or from CREATE TABLE AS, so the best solution is to FeatureClassToGeodatabase into a file geodatabase, then right-click delete in the database.  You can reload into the old name after that

- V

[BartPittari]

That may work.  Would I necessarily have to recreate the table from scratch or would a TableToTable function (Import Table to Geodatabase) work just as well?

[VinceAngelo]

TableToTable/TableToGeodatabase doesn't support geometries. It would need to be FC2FC/FC2G.

- V

[BartPittari]

But if the shapes were no longer needed on it, and they were nulled out once exported via calculation, then wouldn't you just essentially have a table?

[VinceAngelo]

If a field of type geometry exists in the column list, even if it's always NULL, then TableToTable is not the right tool.

- V