Preventing Users from Leaving the Main Switchboard

[Rita]

Help! Can someone tell me how to prevent users from exiting the main
switchboard. Someone is changing my queries/forms. I need to be able to edit
queries/forms. I thought I went to a workshop and someone told me there was a
way of doing this. THANKS!!!!!

 

[KARL DEWEY]

Have you thought about building them their own front ends?

 

[Rita]

My database is split, if that's what you mean my front end? Ten people use
the database and one person is making changes to queries. I would like to
prevent anyone from leaving the MAIN SWITCHBOARD. I thought there might be a
way of preventing them from exiting the switchboard. At a seminar I know a
guy told me how to do it, but I forgot. Then when you want to get into
forms/queries, you hold down the "S" key when opening???? That's all I
remember from him about the secret trick.

 

[KARL DEWEY]

Holding down the SHIFT key when opening the database avoids running any
macros or events that open forms.

 

[Rita]

So do you know of a way to keep users from exiting the main switchboard?
Thanks!

 

[KARL DEWEY]

No.

 

[Tim Ferguson]

So do you know of a way to keep users from exiting the main switchboard?

User level security will protect your queries and data...

It's easy for a knowledgeable user to create a new mdb and attach to your
tables and queries, so that just protecting one front-end mdb will not
solve your problem.

Hope that helps


Tim F

 

[Rita]

So I need to protect the front and back end then.

 

[tryfanman]

It is possible to disable the shift key used when opening an mdb. A
quick google search turned up the following : "you can set the
AllowBypassKey property which disables Shift". So why not give that a
whirl?

If you manage this you could also set your queries and tables to
hidden in your back end so they won't show up in the database window
if someone opens it up.

 

[Rita]

My first thought was to just hide everything--which I did. When I merge,
though, the query needs to be visible so I just made those queries visible.
Thanks for disable shift suggestion!

 

[Tim Ferguson]

So I need to protect the front and back end then.

It depends.

1) The data are vital. If users are making unauthorised changes to the
actual records, then the back end needs to be properly protected with
Access user-level security. Bear in mind that this is not bullet-proof --
a user would have to go seriously out of his way to break in, but such
solutions are available to purchase. If the consequences of that could
result in loss of life or limb, or serious legal challenges etc, then you
might need to think about moving up to an industrial strength dbms. Most
of the time, Access ULS is more than enough.

2) Breaking the front end can be a pain in a bigger or lesser degree.
Someone making unwarranted changes to a query may at worst result in an
unusable form, or at best simply make more work for himself. This might
or might not be a disciplinary issue within the organisation if you think
he is wantonly interfering with your software. You can protect the front
end using ULS. On the other hand, it's probably just as easy to overwrite
the front end with a new copy of the original every day, session, close-
down, or whatever.

3) Converting the front end into an MDE is also a good way to stop people
interfering with the user interface. If you are paranoid about someone
purloining your secret and unique VBA code, an MDE will stop that too.

4) A knowledgeable user can access the data from lots of platforms, not
just your front-end. Even MS Word and Corel Draw have VBA environments
that will happily read and write to a mdb database. That is exactly why
all integrity constraints, ValidationRules etc need to be enforced at the
db engine level, not in the user interface.


Hope that helps


Tim F