Publishing Tables to Portal - Best Practices Questions

MonicaBeaton

Hi all,

I'm working within an SQL Server Windows based GDB Enterprise federated with Portal for ArcGIS 10.9.1. My question is whether there is a difference between the three different ways of getting a table into Portal that affects editors working on the SDE/Default data on the SQL Server? I want to limit any effects that might slow down the technicians editing in their versions but I can't find documentation anywhere on how published data affects the underlying SDE/Default SQL GDB. Here are the three methods I have tried:

1. Publish stand alone table from ArcPro - results in a hosted layer. Has the option to be copied or referenced

2. Publish during bulk layers from Data Store process - results in a table that looks like a feature layer

3. Publish as a Map Service from ArcPro with other feature classes - results in a table that keeps it's relationship classes but is still not hosted. Can be copied or referenced

My burning questions:

- Are referenced layers causing calls to go to our SDE/Default SQL GDB and potentially slowing down editors' access to the same data?

- If we 'copy' the data to the Portal (and not choose referenced), will changes editors make on the SQL GDB automatically appear or does one then need to set up regular 'syncing'?

I am just curious as to what some other folks' are doing as part of their 'Best Practices'? Thanks!

AngusHooper1

- Are referenced layers causing calls to go to our SDE/Default SQL GDB and potentially slowing down editors' access to the same data?

A referenced map or feature service does have a connection to your enterprise geodatabase. Depending on the use case, it may slow down other connections to the database. For example, your map service may allow complex querying of the data.

- If we 'copy' the data to the Portal (and not choose referenced), will changes editors make on the SQL GDB automatically appear or does one then need to set up regular 'syncing'?

A hosted feature layer is no longer associated with the enterprise geodatabase. You could delete the entire database and it would not impact the HFL.

 

There are multiple ways to achieve what you want so it is hard to provide advice. I would recommend going with the easiest option - a simple map service pointing to your feature classes in the enterprise geodatabase. If you find that is slow then you could look into having a view or read-only db permissions. You could also use child replicas to export out file geodatabases which can subsequently be used for a map service. You could also run automated ETL scripts to update the HFL based on the contents of the egdb feature classes. There are lots of options and it is a common requirement amongst the community.