Unregister with Geodatabase GP Tool

[Bud]

ArcGIS Pro 2.6.8; Oracle 18c 10.7.1 EGDB:

I've created a database view in an enterprise geodatabase and set up privileges. I've used the Register with Geodatabase geoprocessing tool on the view.

Now, due to changing requirements, I want to remove some fields from the view. I can do that in the SQL Client. However, changing fields will break the registered view. The view will error out in ArcGIS Pro when I open the attribute table:

In order to fix the registered view, I would need to:

1. Delete the view using ArcGIS Pro (to ensure the Register with Geodatabase system table records get removed).
2. Recreate the view using the SQL Client.
3. Re-register the view with the geodatabase.
4. Set up the privileges again.

That's doable in a pinch, but is not an efficient process. I would rather unregister the view with the geodatabase and re-register it, instead of needing to delete it and recreate it.

Could an Unregister with Geodatabase geoprocessing tool be added to ArcGIS Pro?

[Bud]

Another scenario:

When we register a view with the geodatabase, the extents are registered too -- permanently. If the extents of the underlying data changes, there's no way to change the extents that are registered with the geodatabase. So when I add the view to an ArcGIS Pro map, it zooms to the original registered extent, not the new extents of the data.

If I understand correctly, the only way to change the registered extents is to delete the view, re-create it., and re-register it That seems problematic. The extents of data do change over time. I don't want to recreate my view each time that happens.

I'm aware that I can manually set the extents when registering with the geodatabase:

That works, but I don't necessarily know what the possible extents of the view will be. So setting the extents initially is just a guess and will likely need updating in the future.

[RyanDavis3]

I wholeheartedly support this idea. As someone who finds working with data in SQL Server much more flexible, it is frustrating that we have to do these steps manually.

It is totally conceivable that Esri could develop a Python based tool to delete all of the metadata records in the SDE objects. It seems foolish that we have to delete, rebuild, and re-register an object if anything changes.

An alternative suggestion could be to "Update GDB registration" or "Re-register with GDB" when the object changes.

[Bud]

@RyanDavis3 

An alternative suggestion could be to "Update GDB registration" or "Re-register with GDB" when the object changes.

That's a great idea.

[Bud]

Another problem due to the lack of an "Unregister with Geodatabase" or "Re-register with GDB" GP tool:

I want to start using metadata in my Oracle EGDB. But I currently can't use metadata on my database views (~100) because they are not registered with the geodatabase.

Side notes (from my personal notes):

I’ve looked into GIS metadata in the past, but came across a limitation:

Our GIS database views can’t have metadata currently, since they’re not registered with the geodatabase. I don’t normally register views with the geodatabase because registering makes the views difficult to update the SQL; the view would need to be deleted, recreated, re-registered, and privileges redefined, which is cumbersome and error-prone. Whereas unregistered views are easy to update via SQL. Additionally, newer versions of Pro are better at handling unregistered views, so registering views won’t have as much benefit in future versions in terms of avoiding bugs.

As mentioned, if I were to register my database views with the geodatabase, then if I wanted to make changes to the views, I'd need to do the following: delete, recreate, re-register, and redefine privileges.

Additionally, that process would delete the metadata. So I'd need to always remember to backup my metadata somewhere (Microsoft Word?) and then re-populate the metadata in the new database view. Often, I'd forget to back up the metadata somewhere and lose my metadata info. If, by chance, I did backup the metadata, then it would still be inconvenient to recreate it.

I'm aware that I could create a custom Python script or model to replace the view with all the steps outlined above. But I don't think I should need to do that.

As an alternative, I'm leaning towards managing "metadata" in an Excel spreadsheet instead. 

Let me know if I'm missing something. I'm new to metadata.

@MarceloMarques might find this interesting.