Review conflicts detected during a refresh
When you use the Refresh function, some of the received changes might be to items that you have changed in the image. If you have not sent your changes to the SDB, then depending on which properties you changed, your changes are overwritten. After the refresh operation completes, the item's properties and relationships in the image will reflect the changes that were received from the SDB.
The Conflicts detected in SDB Refresh at transaction window describes the conflict that existed between data in your image and data in the SDB, prior to the refresh.
Records in the SDB describe changes that a user made to data; when you click Refresh, you receive the changes made by other users. In the SDB, changes to particular groups of properties are stored together in the same record. For example, the list of resources that are allocated to an activity are stored together. So, if you change the location of an activity then click Writeback, the record that is added to the SDB references the changed location, but also references the unchanged staff member. When another user clicks Refresh and they receive that record from the SDB, it must be applied to the image on their workstation in its entirety.
A conflict scenario occurs when multiple users modify the properties of the same item or relationship, and two or more of them modify at least one of the properties that are recorded together in the SDB.
For example, in Writeback to send their changes to the SDB. When you click Refresh, you receive a record that describes which resources were allocated to that activity in the other user's image, when that user clicked Writeback., you might change the location that is allocated to an activity. At the same time, another user might change the staff member that is allocated to that activity, then click
This received record is applied in its entirety. So, your location change is overwritten, and the staff change made by the other user is applied to your image. The Conflicts detected in SDB Refresh at transaction window appears and describes those changes.
The data in the Conflicts detected in SDB Refresh at transaction window is presented as a set of nested tables. You can click the + and - icons to expand and collapse tables in the window; doing so can help you browse the information more easily.
To review the changes made to items that you had modified, follow these steps:
- Identify which items have changed. Each row in the outermost table corresponds to an item; the tables nested in that row tell you which data changed. By default, each row contains the Object Type, Name, and Host Key of each changed item.
- For each item, identify the properties and relationships that were changed. Within each row in the outermost table, a nested Change Details table contains a row for each property and relationship that changed. For example, the Property column of the Change Details table might tell you that the Scheduled Staff of an activity was changed.
- For each change to a property or relationship, review the change that occurred. Within each row in the Change Details table, a nested table contains the change to data. For example, a row might contain a Relationship Changes table in the Scheduled Staff row; the table tells you which staff member was removed, and which staff member was added.
Scientia Ref: 3800. For Enterprise Course Planner 3.12 to 3.13. Copyright © Scientia Ltd. 2017