Random Crashes on Save Edits

SamuelColdiron · ‎01-25-2019

Hey All,

Several of our editors have experienced random crashing when saving edits on R&H items in ArcMap (10.6.0). A bulk of them are following a Cartographic Realignment, but other are after a Reassign or other R&H Tools. We have not been able to narrow it down to a common theme yet and we're wondering if any one else has experienced anything like this?

We have tried several things like making sure all imagery is turned off, making sure all events are turned off, making sure no events (except Centerlines, Calibration Points, and LRSN) are in the MXD when they save.

Thank you in advance for your help!

ScottFierro2 · ‎01-28-2019

We are in 10.5.1 and have recently begun seeing a similar issue. We've been working an active ticket with support for several weeks now where ArcMap crashes while users are in open and active edit sessions. In nearly all cases this seems to occur during Apply Updates but we haven't pegged down any specific tools or workflows leading up to the Apply Updates which seem to be the trigger.

Our bigger issue has not been the crash itself, its been when the crashes occur, the sessions are failing to get closed inside the SDE.STATES table leaving the state with a <NULL> value which looks to the system as if the user is still in an open working session. There's no way when the user gets back in to re-establish themselves back to the same STATE record and if the user continues doing work it introduces big headaches once working to do our rec/post to DEFAULT. Our current workaround has been immediately after a crash we delete the user version and rebuild the user version back then let the user get back to work. Doing this ensures the user goes against a different STATE and then before we run our weekly rec/post to DEFAULT we run compress first thing to flush out these bad states.

Like I said, sounds similar but maybe different and when we hear anything back from ESRI can get an update out.

SamuelColdiron · ‎01-28-2019

Yep, that sounds exactly like what we have going on. We ran into the same issues with the Editors not being able to get back in to work. So far we have been successful in just clearing the locks out and disconnecting the user from the database. We will keep a closer eye on the STATEs table now that you mention that to make sure we aren't missing anything.

RayChilcote · ‎01-29-2019

We've had the NULL issue at NCDOT. The source of our issue was a hanging service layer lock. However, I can see this happening in several areas of the ArcGIS SDE environment, namely due to processing speed. A database equivalent is a Deadlock. But here changes have already been made to sde_states or its related tables. Some tables get updated but others do not, thereby unassociating the state/lineage/lock/processing information.

For a read on other reportings of the issue and a semi-fix:

https://community.esri.com/thread/206938-error-trying-to-view-locks#comment-739912

The large query in the thread is extremely useful to find and locate the offending rows. Removing them makes ArcCatalog happy again. But like my comment in that thread, beware. While removing the rows makes SDE happy again, you are removing something. If they are orphaned (unassociated) rows of states/lineages/locks that have already been posted, your data is likely safe. Alternately, you could be removing states of unposted data, which you are then removing work that is going to be lost. You may/may not have further work with the version (which now may be unusable) and/or route locks.

Bit of bad news: according to the above thread, this isn't fixed in Pro. An Esri employee says it doesn't exist at 10.6+, but several users report the issue remaining (including in Pro). BUG-000110574.

My big question is: if Esri says they are going to fix it... what are they fixing? Will the NULLs that cause the "Column value is NULL" error just be ignored? Or are they deleting unassociated rows? Or...? Any of these are impacting to us.