Highway agencies manage and maintain a broad spectrum of linear referencing data about their roadways, and workflows may vary greatly. An LRS editor may be cartographically realigning a route from Esri Roads and Highways, while an event editor may be in the field changing the event attributes of a roadway. When multiple users edit the ALRS in an enterprise geodatabase, they can encounter versioned conflicts on route elements and events. To facilitate the coordinated editing of an ALRS in a multiuser geodatabase, Esri Roads and Highways enforces a set of conditions and behaviors that prevent users from editing a route or event without the acquisition of a lock.
When conflict prevention is enabled, users define a lock root version in the ALRS properties. The lock root version is the parent version from which all child versions are created. After edits are made in a child version, the changes are posted to the lock root version.
The following sample workflow demonstrates the different scenarios in which an editor will be presented with conflict prevention alerts. Refer to the legend below when viewing the figures provided in this topic.
Conflict prevention example workflow in Event Editor
Event Editor A and Event Editor B have been assigned the task of changing the speed limit attribute for the speed limit event layer on several routes. The state has noticed an increasing number of accidents along these roadways and is attempting to mitigate future incidents by decreasing the speed limit from 55 MPH to 45 MPH.
Each editor opens her own version of Event Editor and begins to edit the speed limit event records for the routes in the queue. They browse to the location in which the edits will be made, but because the two editors have not coordinated their work, they select the same event record to edit. Both editors are prompted with the following message:
Event Editor A steps away from her desk before reading the message. Event Editor B reads the prompt and clicks Yes to acquire the lock. Event Editor A returns to her desk and attempts to acquire a lock for the event record. However, she is alerted with the following information:
Event Editor A cannot acquire the lock because it has already been acquired by Event Editor B. She will not be able to acquire the lock until it has been released by Event Editor B.
Event Editor B moves on to the next event records in her queue. She uses the Route Find tool to search for the route on which the event record exists. She uses the Select by Geometry tool to select the route and acquires a lock on the event record. Before she can make any edits, she is notified that her surveying expertise is needed in the field. She decides to complete the edit on her Wi-Fi enabled tablet and takes her work with her.
She arrives in the field and performs her tasks. During her downtime, she pulls out her tablet to complete her edit. She browses to her edit area and selects the event record, but she receives the following alert:
The Event Editor instance she is editing points to a different version from the one in which the event lock was acquired. She has acquired the locks in Version B, but is editing Version A. She needs to change the version in Event Editor. She changes the version to Version B in the URL and completes her edits. She reconciles and posts her changes to the lock root version, which releases her locks.
Event Editor A returns to the office and opens Version A to continue with the event edits she and Editor B have been assigned. She begins a new edit session and selects a route to edit, but is prompted to reconcile.
Event Editor A must reconcile because Event Editor B has posted her edits to the lock root version, meaning that Editor A's version is no longer up-to-date with the latest changes. Each time an edit is posted to the lock root version, LRS and event editors will be prompted to reconcile in order to ensure that the child version is in sync with the lock root version.
After reconciling with the lock root version, Event Editor A's version is updated to reflect the edits made by Event Editor B. Event Editor A can see that many of the route edits have been completed by Editor B, and only a few event edits remain in the queue.
Event Editor A selects one of the last remaining routes in her queue to edit. However, she receives a message that the route lock has been acquired by an LRS editor. Although the event lock has not been acquired, Event Editor A is unable to acquire the lock because a route lock must subsequently lock all events on the route. Event Editor A will be unable to acquire a lock on the event until the route lock is released.
She sends an email to the LRS editor inquiring about the route lock. The LRS editor notifies her that a cartographic realignment is scheduled to occur on the route. Once he completes the route edit, he reconciles and posts his changes to the lock root version, which releases his lock.
Event Editor A reconciles to sync her version with the edits posted to the lock root version. She makes her remaining edits. Once her task is complete, she posts the changes to the lock root version.