I have a model that takes a geodatabase of rasters and a featureclass, iterates through the rasters using the FC to calculate zonal stats on each, then creating a field and storing the values in the FC. enter image description here It actually works as intended, though it does have an unhandled python error when I compute a field and try to divide null by a float. My question is about a really weird problem I encountered when I let it run overnight. I queued a couple dozen iterations of this model and left them to run overnight. Sometime in the night, my VPN disconnected from my work network, which caused ArcGIS to lose its connection to the license server and halt operations.

The next morning, I saw this, reconnected the VPN, and it seemed to sluggishly resume the model runs it had not completed before the disconnect, ultimately completing without errors. However, upon looking at the results, everything but the first few were heavily corrupted. My guess is these are the ones that completed before the disconnect happened. For the corrupted ones their geometry is all still intact (draws properly), but the attribute tables are trashed. They either will not open: Failed to load data or have completely mangled values: corrupted For reference, 'Name' should contain a place name and 'prod' should be a number somewhere in the 5-9 figure range.

When I realized what happened, I started replacing the corrupted feature classes to start the whole process over. During this process I realized that if I export features from one of the corrupted files, I get the feature class in the state that it was in before the model run (uncorrupted, but without all the zonal stats loaded into new fields). This tells me that the data is still there. Each of the model runs gave output saying that it was attaching the data to the FC, so presumably, that data should be there as well?

Does anyone understand what happened on a technical level? I assume this has something to do with having the files open for writing and not saving changes properly due to the unexpected halt, but I would have thought ESRI would have planned for that and exited cleanly. I'd like to try to recover the data, but I'm not sure where to start as I don't really understand exactly why they got corrupted.

  • 3
    If you kick the stool out from under someone changing a light bulb, that someone is going to get hurt. There is no way to exit cleanly from write failure in all failure modes. Tech Support has unpublished tools to investigate data corruption; they're the only ones who could provide details on what went wrong. – Vince Apr 13 at 3:35
  • I'm saying I think it was the loss of access to the license server that caused the write failure though. So if my theory is correct, instead of waiting for the person to finish changing this lightbulb before taking their stool, ESRI is kicking the stool out from under them right away. That's what I thought was weird. – ffollett Apr 13 at 3:47
  • 1
    I would see if you can get your AGOL admin to allow you license check out capability so you can avoid this happening in the future. You really don't want to be depending on a VPN for long periods of uptime. – Curtis Price Apr 13 at 7:31
  • 2
    Licence disconnect has a license disconnect failure, not "Unexpected operation". I don't think your theory is correct; I think VPN failure destabilized the I/O subsytem, resulting in write failure. Tech Support has the tools and reachback to Software Development to determine what actually happened (though I doubt it's reproducible). Any "why" answer here would be pure speculation, and Tech Support is your best resource for data recovery. – Vince Apr 13 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.