Select to view content in your preferred language

File geodatabase query layers

12-03-2022 12:49 AM
Status: Open
Labels (1)
Honored Contributor

It would be very helpful if we could create query layers on file geodatabase data.

Even though FGDBs don't have a SQL spatial type like ST_GEOMETRY, it would still help to use non-spatial SQL in full blown SQL queries on file geodatabases.


Hi Bud, this is like your other idea for the equivalent functionality for mobile geodatabases, Create Database View will do the job for you.


A comment from @JoshuaBixby from a related post (Mobile geodatabase query layers) is relevant here too:

Although a Query Layer and Database View could give the same result within a map, the implementation is different.  I think the difference is enough to warrant keeping this idea.

My thoughts are: Query layers are useful for temporary or one-off cases where you don’t want to create an object in the database.


It looks like there’s pretty strong FGDB SQL querying functionality in open source tools like GDBee and QGIS:

GitHub >> GDBee:

The querying functionality available through [ArcGIS] tools is somewhat limited…Open source GIS users have better tools for querying file geodatabases using SQL.

They’re even doing spatial SQL queries on FGDB feature classes. Cool.


This would be a game changer. Query layers are an amazing tool in our arsenal, but being limited to only enterprise GDBs severely cuts down on our possible uses, given that a lot of data lives in file geodatabases.

Especially for users without enterprise GDBs, not being able to use query layers is really limiting.

Like JoshuaBixby and Bud say, although the end result is the same, the implementation matters. Layers are great because they ultimately don't really take up any space. Creating a view (which is also very cool) adds yet another item to clutter the GDB, and is a more permanent solution for what could be a throwaway question.


Another great thing about query layers (and views) is that they can get around several Arcade limitations, such as exporting the value returned by the expression as a field, or symbolizing based on a related table. Being able to use a computed columns with a file geodatabase (or mobile) would open up a world of possibilities.


A use case for fgdb query layers: Control schema locking behavior in ArcGIS Pro