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

"rdemyan via AccessMonster.com" <u6836@uwe> wrote in
news:5d2a41035f7cc@uwe:
[color=blue]
> 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:
>[/color]
WHY????????
Access is very good at handling concurrent users. Access also
supports exclusive mode.

[color=blue]
> 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.[/color]

Right.
[color=blue]
>
> 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.[/color]

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.
[color=blue]
>
> 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.[/color]

Yes. Create a macro that resets the flag. You can then start the
application using the command line to run the macro.

[color=blue]
>
> Thanks.
>[/color]



--
Bob Quintal

PA is y I've altered my email address.

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...[color=blue]
> 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[/color]

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!!!)