Cannot create hosted features services when data are stored in Azure SQL Managed Instances due to the large number of characters included in the conne

[kzoumis]

Hi,

A connection against an Azure SQL Managed Instance includes a large number of characters as shown in the below screen.

When attempting to analyze the data before publishing to create a hosted feature service the 00176 error is returned “Server name path exceeds operating system limit”

According to the ArcGIS Pro Documentation

https://pro.arcgis.com/en/pro-app/latest/help/sharing/analyzer-error-messages/00176-path-exceeds-ope...

“The <value> parameter refers to the staging path, the input directory path on the server, or both, or the path to the data's source data.”

Here the <value> is “Server name”, thus referring to the input directory path on the server. In order to confirm that, I exported the data into a file geodatabase and attempted to create the hosted feature service. The hosted feature service was created successfully, thus the error is not related to the input directory path on the server.

It seems that the reason behind the error is the staging folder in the ArcGIS Pro machine. Though I have shorten this path to “C:\STG”, the error insists. I have also tried to remove the NTFS limitation for long paths in Windows Server 2022, with no luck (I guess that the analyzing process takes into account a certain, predefined number of characters and does not dynamically check the capability of the OS to support larger paths).

Is there any workaround?

[AdamPigg]

Hi, did you find a solution to this?  We have the same issue.  DNS name for the Azure managed instance is long as you describe, but also, the arcgisinput directory is pretty long, and stored on an azure files storage account, and around 113chars in length.  The format used for the config-store location is as per what the ESRI cloud builder produces, so I hope it would work fine.

[AdamPigg]

Ive just done some experiments, and changed the hosting server arcgissystem (which is where the input fodler is located) folder from the storage account to the c: drive, and the error has gone.  So, at least in my case, it seems related to the length of the folder being on a storage account location, plus whatever gets added to the path when publishing.

[AdamPigg]

I also managed to get it to work with the storage account for the service dir, by creating a DNS CNAME record to point to the storage account, which allows a name such as \\<account><uniqueid>.file.core.windows.net\share to become just \\<account>\share.  I then also shortened some of the path folders, saving about 60 chars off the original path.