Hi Bastian,

I believe this article answers your question: https://success.outsystems.com/Documentation/How-to_Guides/Data/How_To_Handle_Concurrent_Updates_on_Application_Data_Records

There is an action GetEntityForUpdate which locks that particular record from being updated. Its also explained well in above documentation.

Hope this helps your query!

Good morning Somesh,

thank you very much for your answer, but unfortunately it does not bring me any further.

With your proposed solution, both employees would already be in the same record and I would only  checking If there was already a change before.

However, since our employees still have to complete various preparatory work before they click the Save button, a few minutes will pass here.

And I would like to prevent that several employees do all the checks on the same record only to find out at the end that a colleague has already done this.

My idea was to make an update to the table when opening the record that employee A is now in this record, but I don't know how to handle it if employee A just closes the browser at the end so that the status is not changed anymore.

I could put a timer in the screen and do an update every minute and check when I open a case to see if the last update was more than a minute ago, but that would be quite a few queries I think.

But maybe there is another solu

I don't think there is an elegant solution, since there is no reliable way of knowing when a users stops "looking at" a record. You can detect browser close, but a users' computer could just crash, or the user could just lose his internet connection. In both those cases, your application would never be notified.

What you described is probably the most advanced automated solution. It would prevent people from opening the same record while also automatically releasing the records after a given time.

If you don't want to have that client-side timer to update the timestamp every minute, you could also show a list of "locked records" to the users so they can manually take over when they see a timestamp is older than 10 minutes for example. That way, you don't have that update every minute, and you give the users full control.

Hi Bastian, 

it's an aggressive locking what you would like to implement. If you really want that, I would advice to have a detail_show page and a detail_edit page, so other employees can access the detail_show always, and some employees want to edit which will decrease the amount of update to the database. Do it in a seperate table having a foreign key to your table. 

you can create a kind of keep-locked-javascript ( a timer calling a client action 'IncreaseLockDueDateTime' in your screen, which will ensure that the record stays locked while the user is in that Edit screen. 

Further you need something when the user is moving from the Edit page to another page, perhaps in a ondestroy handler, to remove the lock, as well as a timer in case the lock wasn't removed due to infrastructure, connection or browser issues.

You need something as well to detect that an employee is locked. You can check it in the Detail screen, but you have to check it as well when accessing the Edit screen. When the lock couldn't be set (implemented as in https://success.outsystems.com/Documentation/How-to_Guides/Data/How_To_Handle_Concurrent_Updates_on_Application_Data_Records ), you might need to inform the user and redirect the user to the detail screen.

Regards Hans

Hello, thank you very much for your answers.

@Hans: It is not my aim to block or stop anything.

My goal is to warn the staff member if there is already another staff member in the case, so that they don't waste time.

If I understood correctly, I can't use the ondestroy event in OS10, at least I haven't figured out how.

I think I will try a mixture of the different suggestions and my previous ideas.

1. when a record is opened, a timestamp is written to a lock table.

2. as long as the detail screen is open, the timestamp is updated in a certain interval (Javascript).

3. when saving in the detail screen, check whether there has been a change in the meantime and display the changes. 

-> The employee can then decide whether to overwrite this or not.

-> The saving action will delete the last timestamp of the case / userid

4. all cases with a timestamp <= 5 minutes are highlighted in the list (icon or colour), so that the employee sees that another employee was / is in there recently

5. when opening a case where the last timestamp is <= 5 minutes, display another warning message that employee XY is/was currently in this case.