How block records for edit if it is being edited by another user? RRS feed

  • General discussion

  • How do I know, LightSwitch uses RowVersion field of conflict resolution for editing. But for my application requires a simple scenario - "block edit records if it is being edited by another user"

    The application for a group of users to do the scenario editing records - "if the user is editing a record, then the record of other users have read-only."
    I can use the method:
    1) On the screen, the user can see all the entries in the tables as read-only. I can lock the controls on the form.
    3) In the table add the logical field "read only."
    2) If the first user clicked the "Edit record", then I can in the method for a button to set the flag "read-only" for this record in table.
    3) If at this time the other user clicks the "Edit" for this record, in the _CanRead method I can check flag is "read only" and to deny a second user to edit.
    4) When the first user saves a record, I can remove the flag "read-only" from the updated record in the _Updated method .

    This method is valid for our application. But there is a danger that if the accident the client user, then the entries in the table will be the flag of "read-only".

    Maybe have the experience of implementing the necessary me a scenario or any built-in LightSwitch?

    Wednesday, September 16, 2015 12:04 PM

All replies

  • I have never tried to do this but perhaps you could query the change set for the selected entity.  If it shows up in the change set that means it is has uncommitted changes, i.e. someone is editing it.  You could then toggle your buttons and/or permissions based on the bool value returned from such a query.  Similarly, you might be able to detect in progress edits using the EntityState api.  These are just some ideas that come to mind.
    Wednesday, September 16, 2015 7:18 PM
  • To implement "pessimistic locking" as you describe will probably require a new LockedByUser column on the entities you wish to do this where the column stores the UserId or Username of the user that locked the record. You will first update the entity with the lock in place before editing it and clear it again on the final save. The various hooks in the data pipeline should allow you to check the locking status as required against the current user. Saving the user ID or username in the lock will also allow other users to see who has the entity locked. You can provide a permission based admin function to release a lock in cases where a user forgets to unlock it.

    Regards, Xander. My Blog

    Wednesday, September 16, 2015 8:09 PM
  • Thanks to all! Will test both ways.
    Thursday, September 17, 2015 9:06 AM