Record lock time-out

[Lars Brownies]

If a user starts editing a record and leaves his desk for 3 hours and then
finishes the edit, will this record be locked for 3 hours or is there some
kind of record lock time out? If not, how do you handle this issue?

Thanks.

Lars

 

[Tom van Stiphout]

On Sun, 12 Apr 2009 08:05:00 +0200, "Lars Brownies"

This is a potentially big topic, but we can circumvent that by doing
this: set the form's RecordSelectors to Yes, set the RecordLocks
property to None (read up in the help file on what this means; it does
NOT mean None), and run some tests. Observe that there are no locks
(stop-signs in the RecordSelector).
Now set the RecordLocks to Edited Record and repeat.

-Tom.
Microsoft Access MVP

 

[Tom Wickerath]

Hi Lars,

In applications I create, I typically have a form open in hidden mode that
checks for user activity. If none is detected in 20 minutes, the application
closes for them. You can find the details in my Multiuser Applications paper,
available here:

http://www.accessmvp.com/TWickerath/articles/multiuser.htm

See the section sub-titled "Close inactive sessions".


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________

 

[Lars Brownies]

Thanks. I get the stop-signs in the record selector when the record lock
setting is set to None, but also when it is set to Edited record. Also, in
both cases I'm not able to start editing the record that is already being
edited. Since I can't do a multi-user testing environment right now, I did
the test by opening 2 different forms based on the same table.

Are you saying I should set the Record lock setting to None?

Lars

 

[Lars Brownies]

Thanks. Not sure I'd want the whole application to quit for this purpose.
Maybe an automatic save after 20 minutes would help as well?

Lars

 

[Tom Wickerath]

Hi Lars,

I suppose you can try that, but what happens if a required field does not
have an entry? Or, some validation rule is violated by a value that the user
typed into the field, before getting up from their desk to go on a three hour
power lunch break? Perhaps it would be possible to trap for the error
number(s) that might be generated in this case, and respond with a Me.Undo
statement to undo their changes.

Personally, I'd just 'kick em out'.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________

 

[Lars Brownies]

You're right, I didn't think that through enough.

I just did a test with a kick-out where a required field was not filled yet.
I noticed that the whole record isn't saved then. Won't that be a problem?

From your experience: how do users respond to the fact that they are kicked
out?

In the kick-out I see a nice side-effect that no users can accidentally keep
the app open the whole night, preventing me to do changes in the backend.

Thanks.

Lars

 

[Tom Wickerath]

Hi Lars,

Won't that be a problem?

Yes, it certainly could be. I'm surprised any of the record saved if the
field was truly a required field. If you were running this test on an
existing record, are you sure it didn't simply revert back to the original
data?

From your experience: how do users respond to the fact that they are kicked
out?

I think I've had one or two users over the years complain about it. I
explain to them that each connection to the file server puts that much more
stress on the server, and if they *really* want to be able to leave the
application open for extended periods then it needs to be re-written with all
unbound forms. Creating unbound forms is not for the faint-of-heart; it
requires a lot more work on the part of the developer, thus increasing costs
for the customer. That's usually enough to make them go away happy.

One of the top causes of JET database corruption is interrupted write
operations. Thus, I really don't want to allow the user to leave a record in
a dirty state for extended periods of time.

In the kick-out I see a nice side-effect that no users can accidentally keep
the app open the whole night, preventing me to do changes in the backend.

Yep. That's just another reason for the 'kick-em-out' approach.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________