Using Relative Updates to Prevent Update Conflicts
Dynamics AX has always included built-in support for relative updates. But it is in combination with optimistic concurrency that this support is truly useful. Relative updates can be applied only to fields of type integer and real. You apply them by changing the FieldUpdate property from the default value of Absolute to Relative, as shown in Figure 7.
Figure 7. FieldUpdate table field property
The difference between an absolute update and a relative update is that an absolute update submits FIELD = <new value> in the UPDATE statement sent to the database, and a relative update submits FIELD = FIELD + <delta value>. The delta value is the difference between the originally selected value and the newly applied value. So if you change the SalesQty field on the SalesLine table from 2 to 5, the update statement contains either SALESQTY = 5 or SALESQTY = SALESQTY + 3, depending on whether you set the FieldUpdate property on the SalesQty field to Absolute or Relative.
When you use relative updates, neither the previous value in the database nor the value it becomes is important to the updating of the application logic. The only important thing is that the difference is added to the value in the database. If all fields being updated in an update statement use relative updates and the record is selected using optimistic concurrency, the RecVersion check isn’t added to the update statement. The previous value isn’t added because it isn’t important, regardless of whether any other process changes the value between the select and the update.
Using relative updates on tables combined with pessimistic concurrency has no benefit because an update lock is acquired when the application logic selects the record, so no other processes can update the same record between the select and the update.
Warning
You shouldn’t use relative updates for fields on which the application logic is making decisions if the select is made using optimistic concurrency. You can’t guarantee that any decision made is based on the actual value of the field. For example, a Boolean field shouldn’t be set to true or false based on whether a relative updated field is equal to zero because another process could update the relative field at the same time. The Boolean field would be set based on the value in memory, which might not be the value that is eventually written to the database.
|
Read more at http://sportstoday.us/technology/microsoft-dynamic-ax-2009---the-database-layer---transaction-semantics-(part-4)---concurrency-models---using-relative-updates-to-prevent-update-conflicts.aspx#w4mGrAYBXZmXddhi.99
