Hi there,
Consider an optimistic locking environment. When a user decides to commit its changes, and data has been (in the meantime) changed by someone else, we ask him if either or not he wants to overwrite data. We achieve this by sending an alert-box just before the transaction begins.
I am currently testing an oera-based framework, and I have a question about the SAVE-ROW-CHANGES method... which, together with the PREFER-DATASET attribute, set buffers' DATA-SOURCE-MODIFIED attribute.
Is it possible to "trap" any changes made by someone else outside a transaction (in other words, without applying the SAVE-ROW-CHANGES method), in order to give the opportunity to the user to choose between "overwrite" or "cancel"?
Thanks
This is certainly possible, but (unnecessarily) complicated. If you implement an optimistic locking check outside the transaction you would still need to do another check inside the transaction to be 100% sure that there is no conflict.
The standard way to implement this with prodatasets is to use SAVE-ROW-CHANGES in a transaction and undo the transaction when an error occurs. If the error is due to a conflict the buffer will be refreshed from the datasource allowing you to get the new data back to the client. (I do not remember whether it is the before- or after-buffer that is refreshed...)
The client need to detect errors and have dedicated logic to deal with conflicts. This is where you would ask the user whether to cancel or overwrite (or merge changes). You use the returned before- and/or after-buffers to reject or reset the client before- and after-buffers according to the users decisions and you may issue another save if he chose to overwrite (or merge changes).
You can look in adm2/dataview.p processSubmitException to get an idea on how to do the conflict resolution. Note that I think it is difficult to get a full understanding just from reading the code (I'm not able to and I wrote it). It supports 4 modes, which is more than you need, but it does not prompt the user for the resolution, so it is not exactly the behavior you are looking for.
Thank you Havard.
I'm gonna try the standard way you've mentioned.
I'll explain a bit more about the dataview code then. It is kind of straightforward, but the use of 2 before-buffers and 2 after-buffers combined with reject-row-changes means that there is a lot going on.
The 4 supported conflict-resolution modes (UndoOnConflict) are:
The basic ADM2 behavior keeps the user changes in the UI and the user needs to undo to get the changes (refreshed or merged) or save the changes.
An approach that allows the user to decide how to resolve the conflict as you suggest is in my opinion better. If the user selects to overwrite you would rollback changes according to the BEFORE and then resave, a cancel would rollback similar to ALL or MERGE. I guess the ideal UI also allow the user to do a manual merge on field by field basis. The NONE mode is probably neither necessary nor suited as a user selectable option.