Error Behavior Strategy - Task Property (Magic xpa 3.x)

Magic xpa provides the following two, pre-defined error strategies:

Recover – Whenever possible Magic xpa keeps the current data view, stays on the current task, and lets the end user recover from the error. Recover lets the end user continue working in the project after an error has occurred.

Abort – Whenever an error occurs, Magic xpa rolls back the current transaction, whether physical or deferred, removes the current data view, and aborts the task in which the error occurs. Abort does not rollback the current transaction for errors that the end user can recover from, such as locking and incorrect login. When an error aborts the task, the runtime task tree is closed to the point above the task that opened that transaction. Furthermore, handlers of the error event will be executed properly.

The following is a list of errors, and the specific behavior that will be automatically applied depending on the strategy selected. For a detailed description of each strategy behavior, see the Engine Directive section.

* In the case of another user who has changed the data, we will not see the change when we park on the row (if the data was in the cache), but if we try to modify the data, the current values data will be read from the disk, and the Record has been changed – restart message appears.

** Auto retry is set according to the Retry Operation Time Interval environment setting.

When using the Position and Data cache strategy, in addition to the position, Magic xpa will store the actual data of the row. If you re-fetch that row you will get the old values stored in the cache. Note that any modifications done to this data from another task will not be seen in the current task. Trying to update a record which was modified in another task will return the message mentioned above.