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; } } }

Read-only feature service from FGDB

berniejconnors

It would be great if we could use a simple FGDB as the data source for a read-only featrue service. This would be helpful with data published for dashboards. Dashboards require a feature service to permit the dashboard elements to update automatically as the data source is updated. But feature services require an enterprise geodatabase. Many of the data sets I want to display in a dashboard do not require a multi-user editing environment. I don't need an enterprise geodatabase. But to publish a feature service, an eGDB is required.

I have tried using a map service with a FGDB in a dashboard but the dashboard will not update unless the user refreshes the browser or, in some cases, I have to open the dashboard in an Incognito tab to see the dashboard elements update with new data.

If my feature service will never be used to add, delete, or update features, why do I need a eGDB? Please make it possible to create a read-only feature service from a FGDB.

Find more posts tagged with

Status: Open

Comments

dgiersz_cuyahoga

Try adding the map service using the URL to the layer you need: https://myWebAdaptor.com/server/rest/services/myMapService/0

We've found that this method lets the app treat the map service layer as a feature layer.

ChrisStiwinter1

That is correct.. again, hosted feature layer solves both issues. If you need a copy of the data, retrieve it from the GIS Server as a File Geodatabase Feature Class. That is why I stated in my first post, that it depends on how you want to update the file geodatabase....

ChristopherCounsell

You cannot publish referenced feature services from a file geodatabase.

Your options are to use an enterprise geodatabase or use a Hosted Feature Layer and update it periodically with your file geodatabase.

I don't anticipate Esri implementing this functionality. It's the role of the more capable enterprise database that is typically accessible with ArcGIS Server for user-managed data, and Hosted content serves the system-managed workflows. There would be a range of technical considerations but the first thing that comes to my mind is the presence of locks. Updating the file geodatabase feature class with an active feature service probably a nightmare.

ChrisStiwinter1

Hi @berniejconnors ,

When you say an "EGDB is required to publish a feature service".. If you have a federated GIS server set as a hosting server then why not just publish the data as a hosted feature service on your GIS server? Then edit the data through the portal as needed.. This way when this service is utilized in a dashboard the data should be reflected in near real time ..? maybe I'm misunderstanding the question.

MikeVolz

Bernie:

I tried to just have Query on Feature Access with a file gdb data source and that is the error that I reported earlier.

ChrisStiwinter1

Hi @berniejconnors .

Depending on how you update the underlying FGDB, could you not just publish the data to ArcGIS Online or Enterprise as a Hosted Service and just edit the hosted FGDB data through your Enterprise connection in ArcPRO. This way I would imagine would update the data in the dashboard as you imagine it should.??

berniejconnors

@MichaelVolz if the feature service is not used for add, delete or update, enabling "feature access" should work for a read-only feature service with a FGDB. I have not tested this.

MikeVolz

The service publishing process will throw an error {Layer's data source is not supported (Feature Services)} when you try to enable feature access for a file geodatabase. Until ESRI makes this possible, it seems like Feature Access should be disabled on that screen if a file geodatabase is the data source.

Blevins_Mark

have you tried going into the server manager where the map image service is published, enabling feature access to spin up a feature layer, and using layer to get around this issue? we were playing around with this and were wondering if there were gremlins we should be aware of...