Startup Code to disable Shift+Enter

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello Guys,

Could anyone help me with the following issue:
I've created a database and secured it thru the user-level security wizard
by creating a updates group with password. And certainly myself is in admin
group.
I need a code or autoexec file which would enable/disable AllowByPassKey
property of the database so that only admin group can ignore the startup
setting by pressing Shift+Enter, but no updates group users. And could you
please also advise where should I place this code if available.

Thanks.
 
Fuad said:
Hello Guys,

Could anyone help me with the following issue:
I've created a database and secured it thru the user-level security
wizard by creating a updates group with password. And certainly
myself is in admin group.
I need a code or autoexec file which would enable/disable
AllowByPassKey property of the database so that only admin group can
ignore the startup setting by pressing Shift+Enter, but no updates
group users. And could you please also advise where should I place
this code if available.

Thanks.
Click to expand...

You misunderstand how that code works. You need to run it exactly once and it
takes effect the NEXT time you open the file (and every time after that). There
is no need to run it every time and there is no way to make it "kick-in" for the
current session.

So... you leave the bypass key enabled on your development copy of the file and
you run the code once on the distribution copy just before sending it out to
your users.

If you want to occassionally gain full access to a distributed copy then you can
run code from some obscure location in the app that re-enables the bypass key.
 
Hi, Alex

Thank you for help but I actually knew about this code which is given in the
Access help and enhanced in the source you've given. But my concern is where
to locate this code within the database so that it automatically runs while
the user-level password secured database is launched and will it identify
itself wether admin is starting the application or user with the
restrictions, or some additions should be made to the code to get this
capability. I tried to use CurrentUser property in combination with this code
and placed it in separate Module but it did not seem to work. Could you
please advise on this issue?

--
Regards,
Fuad


Alex Dybenko said:
Hi,
have a look here:
http://www.mvps.org/access/general/gen0040.htm


--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
Click to expand...
 
Thank you very much, Rick. I really misunderstood the usage of this code. And
last one: does running of the enhanced code that Alex recommended mean that
only admin will be able to re-enable the by pass key by the method of running
code "from obscure location in the app" as you stated, i.e. application can
be considered to be fully "locked" for other users. And could you please just
shortly describe the way of the running this code from obscure location.
Sorry for annoying you with details, it's first time I do these security
things and am absolutely weak on that.

Thanks.
 
I did this once by indentifying a specific user in the code. If that user
logged in, the code would unlock the bypass key. That is the ony thing I
used that user ID for.

So to get into the app, log on as the secret user, close the app, then open
it again with the shift key down.
 
OK, Dave. So then where did you place your code to activate it after the user
logged in by his own ID (or password). And you seem to have used CurrenUser
property to identify the logged user...
 
Give yourself some backdoor within the app. Clicking on a header logo for
example.

In the click event for that logo, check the user's priviledges (or ask them
for a separate password), if they pass the test, run the code to enable the
bypass. Display a message box telling the user that they need to close &
reopen the app with shift pressed to gain full access.

If you do this, you should consider adding a line of code to whatever code
runs from AutoExec (this is the code that gets bypassed when your DB opens)
that DISABLEs the bypass key every time it runs. That way, once someone
enables the bypass, it will automatically be disabled the next time anyone
opens the file without holding down Shift. Avoids the risk of leaving the
bypass enabled simple because someone forgot to turn it back on.

Because that someone will eventually be you :-)

HTH,
 
Thank you very much guys !!! I really appreciate your help and now I'm
thoroughly confident in what I should do owing to your valuable
recommendations, and thanks again.
 
Fuad said:
Thank you very much guys !!! I really appreciate your help and now I'm
thoroughly confident in what I should do owing to your valuable
recommendations, and thanks again.
Click to expand...

The "back door" that you're advised to allow should just be "extra
insurance". The best advice you got in this entire thread is to maintain a
development copy which does allow opening with the bypass key.

For convenience in maintenance even if it is a single-user application, and
extreme convenience in deployment if it is multiuser, you should have the
front-end (aka user interface: queries, forms, reports, macros, and modules)
in a separate database, with each user having their own copy... that
"production copy" is the one where you "button down" the security and need
to use the options for allow/disallow bypass key, and the back-end (with
tables, relationships, and data) in a separate database in the same or
shared folder. Tables in the back-end will be linked from the users' front
end databases, so you can update the application and provide a new copy to
the users without having to transfer/manipulate the data.

Larry Linson
Microsoft Access MVP
 
Back
Top