Kevin,
Reader’s Digest version, we delete versions and do not attempt to resolve conflicts.
I would have to say that one is taking a gamble when using the edit calibration tool and other editors (desktop and RCE) are actively editing. I have used the tool and not seen the conflict. I would say looking back that I was lucky. For NC we have at least 4 times a year we are at state zero for SDE and have editing frozen to the enterprise. I have used that time to use the edit calibration tool to fix a number of our routes before allowing the enterprise to start editing again.
This past year we have had a number of what we call corruption issues of our production database, and because of that and an overabundance of caution, we delete versions because of the unknowns of allowing the data to posted. While it may appear fine, the concern is future editing of that route and the unknown of what may happen. We could have saved some versions as not all were impacted (desktop and rce wmx jobs) but a decision was made to restore the database to a last known good which meant the enterprise lost a few days’ worth of edits.
Below is the test case I used to recreate the issue as it matched our normal editing practices and I sent this to esri so they could also recreate the issue which they were able to do.
Two editors are making desktop R&H linework edits (cartographic realignment, create, extend, realignment, the order and routes edited doesn't matter) and posting data as they would do normally. While a third editor was using edit calibration point tool to modify the first calibration on a selected number of routes who’s starting calibration measure was not zero (in practice we don't recommend editors use this function in the course of normal editing. This was practice even before discovering the bug. We only use the tool when there is known issues and only on those problematic routes). While editing the calibration point, the third editor is prompted to gets locks for each route. The other editors continue posting data. The third editor is prompted to reconcile before getting a lock, reconciles and then selects yes to get a route lock. Tool finishes updating the calibration point. Third editor runs a manual apply updates to push measure changes downstream. Select in attribute table next calibration point. Select pan to selected calibration point and attempt to edit next route. Repeat until issue occurs. For us, on the fourth edit to calibration points, after reconciling, the conflict box appeared for the third editor. Esri should be able to prove the internal triggers that create the error. We decide not to deep dive further on the issue as is was reproducible and easily preventable. Additionally while not practical we have a workaround that we can use to mitigate the occurrence.
Some of our lessons learned:
1. Post frequently but be cautious of impact to other editors who will have to reconcile (this is causing other operational issues, look for a future posting to discuss esri's enterprise solution)
2. When an issue is detected, report it immediately (we are actively monitoring the system's health and we have found that this can help contain issues and help prevent enterprise data loss)
3. Keep business units updated, communication is key with the enterprise spread out over multiple physical locations
4. Document issue for reporting to esri and future use
Hope this helps,
Ryan
