BUG-000117296 [Conflicts introduced on routes when doing calibration point edits while route edits are being posted in another version]

12-10-2018 08:11 AM
Labels (1)
Occasional Contributor III


Using Edit Calibration while users are posting any other route edits.

Esri Workaround: don't use edit calibration while editors are posting route edit changes. 


The workaround is not practical in an active enterprise environment with multiply route editors. 

While possible, it is not probable if doing one edit. I ran across this while doing only edit calibration work on many routes in a short time period.

Tags (2)
0 Kudos
2 Replies
New Contributor II


Thank you for posting this.  We are increasingly finding minor conflicts arise in our R&H geodatabase when we have Conflict Prevention enabled and I wanted to ask about what set of circumstances, presumably during an edit session, would create a conflict.   We are also using 10.5.1.  I'm not sure if the situation you describe is the same one in our case or if something else is happening but if I understand this correctly, you can not currently safely use the R&H tool edit calibration points while anyone else is editing the network in another version.  If that is the case, I certainly agree the workaround is not practical.    NYSDOT's Highway Data Services Bureau typically has 5 or more network editors working in separate edit versions. 

Do you have a system for resolving the conflicts or do you visit each one to resolve?

Thanks, Kevin

Occasional Contributor III



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,