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, written in Python, to si… 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?
... View more
