By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,669 Members | 2,203 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,669 IT Pros & Developers. It's quick & easy.

Have form only open for one user at a time.

P: n/a
My application is split into a front end and back end. Each user has their
own copy of the front end.

There are a few forms I only want to be open for one user at a time. So I've
implemented the following strategy:

1) Create a table with the fields FormName, OpenStatus, FormUser
2) When a user tries to open the form, the code in the Form Load event checks
the table for the OpenStatus value (True/False).
3) If the status is True, then someone else has the form open on another
machine and this user cannot open the form. A BypassCloseFlag is set and then
DoCmd.Close for the form is executed. The BypassCloseFlag prevents execution
of the code in step 5 below.
4) If the status is False, then the table record is updated to FormUser =
CurrentUser ande OpenStatus to True.
5) In the Form Close event, there is code to set OpenStatus to False and
FormUser to spaces as long as ByPassCloseFlag is not set to true.

This is all working fine, but I have the following concern.

What if the system crashes while this form is open and the user cannot close
it in a normal fashion which sets the table field for OpenStatus to False.
Subsequently, isn't there the potential that OpenStatus could remain set to
True with no one being able to open the form at all.

My users do not have any direct access to tables because I have locked down
the app using the startup options. Also, no user has direct access to the
backend file so it can't be opened.

Someone might suggest try it and see what happens. However, I don't wnat to
crash my system on purpose for testing. I might try it after I've implemented
something that I've been reasonably assured will work. But crashing the
system on purpose makes me nervous.

I guess I could include a form for the administrators to be able to reset the
OpenStatus to false for all form names in the table, but I wanted to see if
someone else has a suggestion.

Thanks.

--
Message posted via http://www.accessmonster.com
Mar 12 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in
news:5d2a41035f7cc@uwe:
My application is split into a front end and back end. Each
user has their own copy of the front end.

There are a few forms I only want to be open for one user at a
time. So I've implemented the following strategy:
WHY????????
Access is very good at handling concurrent users. Access also
supports exclusive mode.

1) Create a table with the fields FormName, OpenStatus,
FormUser 2) When a user tries to open the form, the code in
the Form Load event checks the table for the OpenStatus value
(True/False). 3) If the status is True, then someone else has
the form open on another machine and this user cannot open the
form. A BypassCloseFlag is set and then DoCmd.Close for the
form is executed. The BypassCloseFlag prevents execution of
the code in step 5 below. 4) If the status is False, then the
table record is updated to FormUser = CurrentUser ande
OpenStatus to True. 5) In the Form Close event, there is code
to set OpenStatus to False and FormUser to spaces as long as
ByPassCloseFlag is not set to true.

This is all working fine, but I have the following concern.

What if the system crashes while this form is open and the
user cannot close it in a normal fashion which sets the table
field for OpenStatus to False. Subsequently, isn't there the
potential that OpenStatus could remain set to True with no one
being able to open the form at all.
Right.

My users do not have any direct access to tables because I
have locked down the app using the startup options. Also, no
user has direct access to the backend file so it can't be
opened.

Someone might suggest try it and see what happens. However, I
don't wnat to crash my system on purpose for testing. I might
try it after I've implemented something that I've been
reasonably assured will work. But crashing the system on
purpose makes me nervous.
It should make you nervous. but you could test on a copy of BE
and copy of FE and just kill Access using the task manager.

I guess I could include a form for the administrators to be
able to reset the OpenStatus to false for all form names in
the table, but I wanted to see if someone else has a
suggestion.
Yes. Create a macro that resets the flag. You can then start the
application using the command line to run the macro.


Thanks.


--
Bob Quintal

PA is y I've altered my email address.
Mar 13 '06 #2

P: n/a
You should have a form for admin reset.

You should also include a date/time field
so that you can see when the record was last
set.

You may also wish to include a computer name field,
so that you can see which workstation the user
is/was at.

You can also use ADO to check the user roster to
see if the user who has the form locked is still
connected, but that will have the same failing:

If the user crashes without disconnecting, the
user roster maintained by Jet will have the same
error as you do.
"rdemyan via AccessMonster.com" <u6836@uwe> wrote in message
news:5d2a41035f7cc@uwe...
My application is split into a front end and back end. Each user has their
own copy of the front end.

There are a few forms I only want to be open for one user at a time. So
I've
implemented the following strategy:

1) Create a table with the fields FormName, OpenStatus, FormUser
2) When a user tries to open the form, the code in the Form Load event
checks
the table for the OpenStatus value (True/False).
3) If the status is True, then someone else has the form open on another
machine and this user cannot open the form. A BypassCloseFlag is set and
then
DoCmd.Close for the form is executed. The BypassCloseFlag prevents
execution
of the code in step 5 below.
4) If the status is False, then the table record is updated to FormUser =
CurrentUser ande OpenStatus to True.
5) In the Form Close event, there is code to set OpenStatus to False and
FormUser to spaces as long as ByPassCloseFlag is not set to true.

This is all working fine, but I have the following concern.

What if the system crashes while this form is open and the user cannot
close
it in a normal fashion which sets the table field for OpenStatus to False.
Subsequently, isn't there the potential that OpenStatus could remain set
to
True with no one being able to open the form at all.

My users do not have any direct access to tables because I have locked
down
the app using the startup options. Also, no user has direct access to the
backend file so it can't be opened.

Someone might suggest try it and see what happens. However, I don't wnat
to
crash my system on purpose for testing. I might try it after I've
implemented
something that I've been reasonably assured will work. But crashing the
system on purpose makes me nervous.

I guess I could include a form for the administrators to be able to reset
the
OpenStatus to false for all form names in the table, but I wanted to see
if
someone else has a suggestion.

Thanks.

--
Message posted via http://www.accessmonster.com

Mar 13 '06 #3

P: n/a
there's always a risk when you are using a semiphore to control access
to an object that if it crashes you'll be left with it in a permamently
locked state. The only full solution is to establish proper client
server communication - not easy to replicate with Access FE / BE.

The way I see it, you have 2 real options
1. Create an admin panel and give one user re-setting abilities
2. Look at your DB design - you should not have to lock users out of a
form for exclusive editing... Access can handle concurrent updates
quite well and there is probably a more workable design that can be
employed. (unless you're taking orders from one of those control freak
user clients that don't know what they are talking about - man I hate
that sh!t!!!)

Mar 13 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.