nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automatically register database view with file geodatabase

Bud

ArcGIS Pro 3.2; file geodatabase:

When creating a database view in a file geodatabase, the view doesn't get automatically registered with the geodatabase. The user needs to do it manually using the Register with Geodatabase geoprocessing tool.

That seems like an unnecessary manual step that people often overlook.

As Esri Support said:

Case 03490768 - Database view on feature with nil geometry hangs when added to map
"Registering views with geodatabase also helps in resolving many issues related to views."

Can that behaviour be changed so that FGDB views get automatically registered when the view is created?

Find more posts tagged with

Geodatabase

Closed

Status: Closed

Comments

Bud

I understand why mobile and enterprise geodatabase views do not get automatically registered with the geodatabase:

It's possible to create database views in those GDBs from outside ArcGIS using a SQL Client. So the database view wouldn't get automatically registered with the geodatabase in that case, so it makes sense that views created from within ArcGIS Pro behave the same way, for simplicity/consistency's sake.
Likewise, there are cases where we prefer to leave mobile and enterprise views as non-registered. With non-registered views, we can make DDL changes using a SQL client without causing issues (and without recreating the view and re-defining privileges), which is extremely convenient when it comes rapid SQL development in ArcGIS Pro (more convenient than query layers in EGDBs). Whereas, it's dangerous to make DDL changes to registered views; their design is static and should not be modified.
So it's very important that mobile and enterprise views do not get automatically registered. Please leave that functionality as-is.
However, file geodatabases are different because they can't be created or modified with a SQL client. The views can only be created or deleted from within ArcGIS Pro, so I'm wondering if they should be treated differently by automatically registering them.

SSWoodward

Thanks for the Idea @Bud

Can you walk me through the workflow in fgdb where you're hitting an issue and are required to register a file geodatabase view with the GP tool? I'd like to reproduce it so we can understand.

What issue are you hitting, and does registering the view solve the issue for you?

Bud

@SSWoodward Good question. I don't recall a specific scenario where registering a view with the FGDB was necessary/solved an issue. I've just been doing it because Esri Canada Support generally recommends registering views:

Case 03490768 - Database view on feature with nil geometry hangs when added to map
"Registering views with geodatabase also helps in resolving many issues related to views."

I've found that registering enterprise geodatabases view solves a lot of issues. I figured the same might apply to file geodatabases.

It would help if Esri could clarify in the docs what GDBs they recommend registering views in. And why registering views fixes issues in some GDBs, such as enterprise GDBs.

As for file GDBs, I wonder if there might be ArcGIS functionality that requires views to be registered. Maybe it's possible to publish a registered FGDB view to a map service? https://community.esri.com/t5/arcgis-enterprise-questions/views-are-not-supported-in-arcgis-server-feature/m-p/1101139/highlight/true#M31162

If the Register with Geodatabase GP tool is not intended to be used on FGDB views, then that tool should be changed so that FGDBs are not valid inputs.

SSWoodward

When to register a view depends on how you and your workflows intend to use the data, so specific recommendations on how you should manage your views would be difficult to provide. In general, if you want to be able to interact with the view as a geodatabase object in an enterprise geodatabase, registration is required.

The general guidelines for views are in the doc, which can be found here.

If you encounter any bugs related to using fgdb views that are addressed with registration, please give us an update.

For the GP tool idea, we don't have a pattern of GP tools performing differently in different workspaces. For consistency, creating a view using the GP tool or create view wizard will create an unregistered view in all workspaces.

Bud

@SSWoodward It sounds registering a FGDB view with the GDB makes it so the view can be published in a map service:

Can a FGDB database view that is registered with the geodatabase be published as a map service?