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. The users might not edit the same property; a conflict occurs if they edit distinct 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 (see 1, below) corresponds to an item. By default, each row in the outermost table contains the Object Type, Name, and Host Key of each changed item.
- For each item, identify the relationships and properties that the Refresh function has changed in your image. Within each row in the outermost table, a nested Change Details table (2) contains a row for each relationship and property value that the Refresh function applied in your image. For example, the Change Details table might contain a row (3) that tells you that the Scheduled Staff of an activity was changed. The relationship or property that changed is displayed in the Property column (4) of the Change Details table.
- For each change to a property or relationship, review the change that occurred.
- Relationship: Within a row in a Change Details table (2), a nested Relationship Changes table describes the change to data. For example, a row might contain a Relationship Changes table (5) in the Scheduled Staff row; the table tells you which staff member was removed (6), and which staff member was added.
- Property: A row in a Change Details table describes the change to the property value. The SDB Value (7, below) is the new value applied in your image; this is the value that another user wrote back to the SDB. The Local Value (8) is the value that was overwritten in your image.