why won't arcgis attempt to reconnect to network thatwas breifly interrupted?

[JamesHarrington]

I'm working with ArcGIS 10.5.1, accessing an mxd file and geodatabase that are on a network server. Occasionaly the connection to the network is temporarily broken, and I get an error. When the connection is restored, unfortunately, ArcMap will not make any attempt to re-connect. Once it's gone, it's gone forever. You must close the app and lose all unsaved changes. Saving the map file with a different name is a workaround, but this shouldn't even be happening.

The worst part is if you are in an edit session. There is no way so save your edits. There is no way to even see any of the data you were editing, even after the connection has been restored! You must then lose all unsaved edits.

PLEASE fix this ESRI! There is no reason at all why this should ever happen!

[VinceAngelo]

I've used a lot of networks, but haven't seen one with transient failures since I left 10-base2 behind in the early 90s (a tall co-worker kept getting his legs tangled in the coaxial cables running under his desk, and regularly yanked the cable out of the terminator).

Best practice is to avoid using network-shared file geodatabase, this is doubly true for editing over a network, and exponentially true for editing over unreliable networks.

The code to recover from an I/O failure is in the painfully-difficult to impossible range of the difficulty spectrum, so it doesn't seem like this request, if entered in the Ideas queue, would generate a change.

The best mechanism to avoid the pain of network failure is to update to a more reliable network (errors should be on the order of a handful per decade). Changing business practices to copy tables locally before editing them will also help, as would utilizing a PostgreSQL database server to share geometry table resources (with or without an enterprise geodatabase).

Good luck!

- V

[JacobMcCoy1]

I'd like to add my concerns as well.

I have been running into this error very frequently and to date, the above recommendation ('save as' another doc.) has been the best work-a-round yet. I have my data stored on the server on a network drive. As the connection to this server frequently gets interrupted, Arcmap 10.5.1 introduces several errors when attempting to save the document. It's ironic that ESRI's recommendation for this is to save databases/feature classes on a local drive, when my map vendor's recommendation is to keep the data stored on the network.... I feel that ESRI is trying to push customers towards the more expensive option of purchasing Arcserver (~$20k), but that is just my opinion.....

Part of the work-a-round could be to move all of my data to a local drive and have the system back the data up to the network drive daily (as I am the only editor). I suppose those that are working with other editors are not as fortunate....  

[VeerleCaelen]

I am experiencing very similar problems...

All my projects, shapefiles and GDB's are stored on a server so my colleagues can access the GIS-projects whenever they need them. My Arcmap 10.2.1 often loses connection to the server for no apparant reason. I can still access all the data on the server on my laptop so I know the connection to the server is fine. It's just Arcmap that seems to experience these problems. Whenever this happens I get tons of "failure to draw layer" errors and Arcmap almost never recovers from this on its own. Manually reconnecting to my GDB does not work. I usually have to shut down ArcGIS without saving, re-open my project and say a quick prayer. Sometimes this will fix the problem (sometimes I lose some of my work in the process).

I can't store my work on a local drive since my work needs to be accessible to my co-workers and transfering my work from a local drive to the server at the end of the day is very tedious and severs all connections between the layers in the ArcMap project and the GDB. 

It's quite irritating since this problem occurs several times a day. Whenever I work in QGIS I don't experience this constant loss of connection to the server. I really hope ESRI will fix this, but since the problem is still present in the 10.5.1 version, I am not getting my hopes up...

[JamesKelly5]

I'd say a lot of users are experiencing these issues.  Unlike the original reply, many of us are working on less reliable networks, and upgrading to a more reliable one is not feasible nor practical.

In addition, what presents as a network drop out is not necesarily caused by poor networks.  Things such as GC pauses, connections to databases at 100% CPU can also present what appears as a network partition.  Working in cloud environments these network blips are a reality.  See Fallacies of distributed computing - Wikipedia for some reading.  We are working in a distrubuted computing environment as soon as we connect across a network (even to a database) so these things all apply.

My ArcMap edit session fail 10x a day when connecting from an AWS Workspace to a SQL Server Instance running within AWS, in the same aws region / and az. I've seen this in 10.4x, 10.5x, 10.6.x, and now 10.7.x.  ArcMap is the ONLY software I use that has this behaviour, and I use plenty of other software that connects to the same databases via code or GUI.  I was hoping new ArcPro would re-implement the underlying database connection code, but alas, it looks to be very similar when I last checked, experiencing the same dropouts without any option to reconnect.

The generally accepted solution these days is for any network reliant code to have retries built in.  Saying these are "painfully-difficult to impossible range of the difficulty spectrum" is not true.  For some things such as file connection, perhaps, but a database connection should be able to recover relatively easily, as many of the underlying database drivers support this behaviour these days.

We suffer the same issue in our ArcPy scripts, because once the connection drops, the whole process must be recycled for the connection to be re established.  If the connection wasn't persistent per process, we could simply use a python library like GitHub - rholder/retrying: Retrying is an Apache 2.0 licensed general-purpose retrying library, writ...  to handle the reconnection on the occasion when it did drop. 

After all that, is there any chance we could get a database connector that handles transient failures in the network, or at the very least, one that we can manually recover from without having to kill the process?

[RobLane]

I'm seeing this frequently too. We have data in an sde legacy system and I am trying to transfer updates to aws postgis in the interim. Copies just fail without proper error messages to explain the fault. I have to assume there is a network failure and a geodatabase disconnect, and there is no way to recover without restarting the entire process.

Others have told me to export from the db at our end and copy the export to aws S3 attached to the aws RDS geodatabase machine and reimport, but it's a heap of work... and some of these workarounds will work fine in test runs only to become problematic over time.

[mikedav1]

Very poor performance by ESRI.

It is essentially not worth having GDB on a network share.