Check-in/Check-out or Form Locking Functionality is ASP

[Yale]

Hello,

Is it possible to implement a 'Check-in/Check-out' or 'Form Locking' Functionality in an application that is using classical ASP and SQL? Basically, what needs to be done is that if an existing request form is being edited by one user, no other user should be able to edit the same request form. For example, if user 1 is editing request 1... When user 2 tries to open/access request 1, he will be prompted that he cannot edit/access request 1 because user 1 is editing it.

Thanks in advance for the help!

Regards,
Yale

 

[damber]

see this thread:

http://www.tek-tips.com/viewthread.cfm?qid=1141767&page=1

A smile is worth a thousand kind words. So smile, it's easy!

 

[Yale]

damber,

i've read the thread... thanks!

anyways, i have a few more questions -- we are thinking of creating a "lock procedure" ...this lock procedure will be called every time that an existing request is opened... it will basically check if a record is checked-out to someone... if it's not, then it will be flagged as checked-out... (this approach is the same with your approach, wherein additional columns would have to be created to record edit_flag, edit_time, edit_user) ...then, we will be creating an "unlock procedure" that will be called every time that a user closes the request... this procedure will basically just remove the "flag" (contents of edit_flag, edit_time, edit_user)... the problem is... would there be a way that we could still run the "unlock procedure" if for example the user simply closes the browser without saving? or if for example, the user's session times-out?

thanks again for the help!

regards,
yale

 

[damber]

Hi Yale,

I think I mention it in the other thread, but essentially you could have a couple of situations where you would need to time-out the users 'lock'. The first would be where the user closes the browser window without first 'unlocking' the entity. The second would be where they remain on that page for a prolonged period of time.

In either case you should have a background job running in SQL Server (or Oracle/etc) that checks the last checkout time - if it exceeds a limit - e.g. 30 mins, then remove the lock. As long as the posting process always checks that it is still the user that has this locked or the last UPDATE time on the record (another field) is less than the edit start time then you can manage 'late' posters reasonably well.

In the case where the user doesn't close the browser, they may still submit after this period - as above, you should always check on the submit if it is checked out currently to the user submitting and if not - check if it has been updated by anyone else since the lock was removed automatically. To make it more user friendly, use javascript to timeout on the client and popup an alert window to tell the user that their checkout period is about to expire and ask if they wish to extend or cancel the edit.

Hope that helps clarify.

A smile is worth a thousand kind words. So smile, it's easy!

 

[Sheco]

You might also want to consider adding "unlock" functionality to the Session_onEnd() event in your global.asa file.

 

[Yale]

thanks damber and sheco!

i'll try to implement your recommended solutions...

hopefully, i'll be able to do everything correctly... or else... you'll hear from me again... ;D

-Yale

 

[theniteowl]

Yale, my approach is to set the lock flags in the actual record rather than a separate one, setting the info on who has the lock and when they obtained the lock.
In the form page where you open/edit the information, when it first grabs the record it checks if it is already locked and if it is, it checks if the time the lock was set is greater than a fixed amount indicating that the lock expired but was never closed out. If it is not locked or the lock has expired then the lock is updated to the current user and time. A javascript timer executes on client-side to track how long the person has been holding the lock so it will know if it needs to test again before submitting changes though your submission code should check the lock still holds before posting changes just in case.

You could set up lock renewing behavior based on access levels of the person if you wanted and you could always right a function to override a lock by someone with higher privledges.
I did not want a lock to exist fixed until set otherwise because someone might open the record and leave their computer on never closing it out.
The big reason to test prior to submission of changes is that if the lock expired and someone else went in and altered the data then what you have on your screen is out of date and needs to be refreshed. If the person with the outdated info on their screen has made their own changes though you have to figure out how to reconcile the client changes with the updated record in the database. That might be discarding whatever the outdated version changes are or presenting the client with both sets of data where the data differs and letting them choose.

I am going to attempt at coming up with a standard method to do this that we can incorporate into any other apps we develop with the least amount of effort as it takes a lot of thought to get it working right the first time.

I would suggest that from your form page you use an XMLHTTP request to run ASP code that tests for a valid lock so the client can stay on the form page without losing their information and you do not have to go through a form submission then have to repost the data back to the form so the client does not lose their own changes if they need to keep that information.


Paranoid? ME?? WHO WANTS TO KNOW????