Conflict prevention scenarios in Desktop

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 Desktop, 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 is a fictional workflow that demonstrates the different scenarios in which an editor will be presented with conflict prevention alerts. Refer to the legend below when viewing the graphics provided in this topic.

Conflict prevention example workflow

Editor A and Editor B have been assigned the task of cartographically realigning some routes. Each editor opens his own child version of the ALRS and begins a new edit session. 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 route to edit. Both editors are prompted with the following message:

Editor A steps away from his desk before reading the message. Editor B reads the prompt and clicks Yes to acquire the lock. Editor A returns to his desk and attempts to acquire a lock on Route A. However, he is alerted with the following information:

Editor A cannot acquire the lock because it has already been acquired by Editor B. He will not be able to acquire the lock until it has been released by Editor B.

Editor B moves on to the next routes in his queue. Rather than acquiring each lock individually through the Realign Routes tool, he decides to acquire locks on the next few routes in his queue. Using the Selection tool, he selects the routes he plans to edit. He then opens the Locks Viewer table from the Roads And Highways Editing toolbar and uses the Lock Selected Routes tool to acquire locks on his selected routes in his edit version, Version B. Editor B continues to make edits for some time and leaves for the evening.

The next morning, Editor B returns to his desk to continue editing. He opens a new instance of ArcMap and browses to his edit area in the ALRS. He begins a new edit session and opens the Realign Routes tool. He selects the next route in his queue but is prompted with the following alert:

He has acquired the locks in Version B but is editing Version A. Editor B begins a new edit session in Version B and completes his edits. He reconciles and posts his changes to the lock root version, which releases his locks.

Editor A returns to the office and opens Version A to continue with the route edits he and Editor B have been assigned. He begins a new edit session and selects a route to edit but is prompted to reconcile:

Editor A must reconcile because Editor B has posted his edits to lock root, meaning the Editor A's version is no longer up-to-date with the latest changes. Each time an edit is posted to lock root, LRS and event editors will be prompted to reconcile in order to ensure that the child version is in sync with lock root.

After reconciling with lock root, Editor A's version is updated to reflect the edits made by Editor B. Editor A can see that many of the route edits have been completed by Editor B, and only a few route edits remain in the queue.

Editor A selects one of the last remaining routes in his queue to edit. However, he is prompted with a message stating that an event editor has acquired a lock on the route.

He is surprised because event editors on his team cannot directly edit a network in the ALRS. He opens the Locks Viewer table and filters the locks by user name. He finds the event editor's lock but sees that she has acquired a lock on an event on the route, rather than the route itself.

Although the route lock has not been acquired, Editor A is unable to acquire the lock because a route lock must subsequently lock all events on the route. Because one of the event locks on the route has been acquired by the event editor, Editor A will be unable to acquire a lock on the route until the event lock is released.

He sends an email to the event editor and asks her to release the event lock due to impending route edits. Several minutes later, he receives a response stating that the event lock has been released. Editor A returns to his edit session and selects the remainder of the routes to edit. He is now able to acquire locks on the routes.

Editor A makes the remaining edits. Once his task is complete, he posts the changes to lock root.