For example, if User A opens the application and selects a record,
they can be working on the record as it existed when they opened it.
But if User B was to open the application, select the same record as
was opened by User A and edits and submits the form, then User A is
not aware of the changes made.
Thanks,
Drew
Look in the documentation for the DB you're using for record locking. Some do it
automagically. Google it also.
Mike
Thanks for the reply, having a term to search will make this easier.
Thanks,
Drew
When using a web server, you must be very careful if you want to implement
any locking mecanism. For example, you could set a flag with a time limit
somewhere using a stored procedure to make sure that not two user got the
same flag at the same time. Passed that delay, the flag is invalided for
anyone else who may want to take it.
When the user post back his data, the flag is first checked to see if it's
still valid; ie., it has not been granted to someone else because of an
expired delay.
If necessary, you can add some AJAX code into your HTML page so that the
record will get renewed at a regular interval but you must be very careful
about that as you never know when an user will simply walk away for an
extended period of time.
Instead of using a SP for etablishing your own locking flags, you can also
use Application.Lock() and Application.UnLock() - see
http://www.java2s.com/Code/ASP/Session-Cookie/ApplicationLockandunLockVBnet.htm -
but it's not recommended in term of performance.
--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Email: sylvain2009 sylvainlafontaine com (fill the blanks, no spam please)
Independent consultant and remote programming for Access and SQL-Server
(French)
"Joe" <dr00...@gmail.com> wrote in message
news:f0d32c3a-4ba1-475c...@n4g2000vba.googlegroups.com...
> Thanks,
> Drew
You could create a checksum of the original data and store this as a hidden
field in the form so when the user posts the changes back it compares the
checksum with the data in the database and if they don't match then you know
something else has edited it during the time the user had it open. What you
do then is where it could get tricky - the simple solution would be just to
tell the user that the changes could not be made because another user has
edited the data and send the new data back to the user along with the new
checksum which would then allow them to make any further changes and try
posting again. Any method that would involved merging or determining if the
current user should have their changes override the other user will be a lot
more complex to handle.
--
Dan