Shift-F11

[ctdak]

This question has probably been asked numerous times before, but I haven't asked it or seen an answer. I have a "turn-key" application that I am just rolling out and I would prefer not to allow the possibility of a user getting to the database screen where they could mess around with things. Is there any way to disable Shift-F11 access for users while still allowing full access for the administrator/developer? Perhaps a Windows registry change or something

ctda

 

[tina]

on the Menu bar, click Tools, Startup and uncheck the box beside Use Access
Special Keys.
startup options can be bypassed, of course, by holding down the shift key
while opening the db. to prevent that, you have to change the setting of the
AllowBypass database property.
if this is a multi-user db, i assume you're using a FE/BE setup. to protect
forms/reports design and modules, you can password-protect the VB editor
and/or distribute a copy of the FE as an MDE file rather than an MDB.

hth

This question has probably been asked numerous times before, but I haven't

asked it or seen an answer. I have a "turn-key" application that I am just
rolling out and I would prefer not to allow the possibility of a user
getting to the database screen where they could mess around with things. Is
there any way to disable Shift-F11 access for users while still allowing
full access for the administrator/developer? Perhaps a Windows registry
change or something?

 

[ctdak]

Tin

Thanks for your answer. I was unaware of what an MDE file is. I have now created an MDE front-end file and deployed that. I have also placed the back-end MDB in a folder on a network drive that is only accessible by administrators

Two further questions

1) You said to password protected the VB editor and/or create an MDE FE. If you create an MDE FE, is there still some security advantage to password protecting the VBA code as well. It seems that the MDE doesn't allow access to code anyway? Is that correct

2) I haven't done anything with the AllowBypassKey database property yet. If you change that to False, then doesn't that disallow even the developer from getting back into the database screen

Thanks again for your help
ctda

----- tina wrote: ----

on the Menu bar, click Tools, Startup and uncheck the box beside Use Acces
Special Keys
startup options can be bypassed, of course, by holding down the shift ke
while opening the db. to prevent that, you have to change the setting of th
AllowBypass database property
if this is a multi-user db, i assume you're using a FE/BE setup. to protec
forms/reports design and modules, you can password-protect the VB edito
and/or distribute a copy of the FE as an MDE file rather than an MDB

ht

This question has probably been asked numerous times before, but I haven'

asked it or seen an answer. I have a "turn-key" application that I am jus
rolling out and I would prefer not to allow the possibility of a use
getting to the database screen where they could mess around with things. I
there any way to disable Shift-F11 access for users while still allowin
full access for the administrator/developer? Perhaps a Windows registr
change or something

 

[tina]

1) yes, that is my understanding as well. there is no code in an MDE to
tamper with, so no use password protecting.
2) yes. you have to create a way for the developer to turn AllowBypass back
on whenever needed, from the open frontend db's user interface. the
alternative is to import all the mdb objects from the original database into
a new one.
i have an AllowBypass "demo" db in A97 and A2000, that i have shared with a
number of people who've posted here in the past. if you'd like a copy, post
back your email address (beware the spam miners!) and the version and i'll
send it to you as a self-extracting Zip file (.exe), or just a plain Zip
file if you'd rather.

Tina

Thanks for your answer. I was unaware of what an MDE file is. I have now

created an MDE front-end file and deployed that. I have also placed the
back-end MDB in a folder on a network drive that is only accessible by
administrators.

Two further questions:

1) You said to password protected the VB editor and/or create an MDE FE.

If you create an MDE FE, is there still some security advantage to password
protecting the VBA code as well. It seems that the MDE doesn't allow access
to code anyway? Is that correct?

2) I haven't done anything with the AllowBypassKey database property yet.

If you change that to False, then doesn't that disallow even the developer
from getting back into the database screen?

 

[ctdak]

I would appreciate it if you would email the demo to me. I need the Access 2000 version and would prefer the plain Zip file. You can use the following address: (e-mail address removed)

Thanks so much
ctda

----- tina wrote: ----

1) yes, that is my understanding as well. there is no code in an MDE t
tamper with, so no use password protecting
2) yes. you have to create a way for the developer to turn AllowBypass bac
on whenever needed, from the open frontend db's user interface. th
alternative is to import all the mdb objects from the original database int
a new one
i have an AllowBypass "demo" db in A97 and A2000, that i have shared with
number of people who've posted here in the past. if you'd like a copy, pos
back your email address (beware the spam miners!) and the version and i'l
send it to you as a self-extracting Zip file (.exe), or just a plain Zi
file if you'd rather

Tin

created an MDE front-end file and deployed that. I have also placed th
back-end MDB in a folder on a network drive that is only accessible b
administratorsIf you create an MDE FE, is there still some security advantage to passwor
protecting the VBA code as well. It seems that the MDE doesn't allow acces
to code anyway? Is that correctIf you change that to False, then doesn't that disallow even the develope
from getting back into the database screen