Disable the ByPass key (97)

Topic

New Reply

Attached is a sample db that will let you have better control over the ByPass (Shift) key. It will help you keep the Riff Raff out.

Special thanks to Jim Bulger for sharing this at another Access forum.

Enjoy!

Tom

Reply | Quote

Replies

Hello Tom,

In some circumstances it is nice (from the viewpoint of the programmer) to disable the Shift key as a bypass. In that case, the code in your sample is very handy.

But remember that it is *not* a substitute for Access security. If you don’t secure the database, people (“riff raff”) will still be able to import database objects (tables, …) into another Access database.

Regards,
Hans

Reply | Quote

Hans,

An excellent point! I guess this is more a technique to keep the honest guys honest.

Thanks,

Tom

Reply | Quote

Hans,

A question for you. Other then the normal access security, are there any other ways to prevent users from importing the database objects to another database?

I have saved a database as a .mde and put on a top level database password. I am not using access security to create named users / groups. The below code is also used to lock up the database during use.

Without using security for groups and users, do you know of any ways that would prevent tables and queries from being imported to another database?

Sub SetStartupPropertiesNone()
Const DB_Text As Long = 10
Const DB_Boolean As Long = 1
‘ChangeProperty “StartupForm”, DB_Text, “Customers”
ChangeProperty “StartupShowDBWindow”, DB_Boolean, False
ChangeProperty “StartupShowStatusBar”, DB_Boolean, False
ChangeProperty “AllowBuiltinToolbars”, DB_Boolean, False
ChangeProperty “AllowFullMenus”, DB_Boolean, False
ChangeProperty “AllowBreakIntoCode”, DB_Boolean, False
ChangeProperty “AllowSpecialKeys”, DB_Boolean, False
ChangeProperty “AllowBypassKey”, DB_Boolean, False
MsgBox “Design Access Disabled”

End Sub

Reply | Quote

I’m not an expert in Access security, so I hope others will jump in.

If you have set a database level password, anyone wanting to import tables/queries from the database would need the password. But I gather that this password is not all that hard to crack; there are password cracking services.

Making a .MDE means that forms, reports and modules are secured.

The other measures you describe (disable bypass key etc.) have no bearing on importing tables/queries; they lock the interface as much as possible.

Regards,
Hans

Reply | Quote

Can you post the link to the other forum (as long as it doesn’t break any rules here)?

And thanks (you and Jim) for the file example!

Reply | Quote

Paul,

The link is here.

If it’s inappropriate for posting, I’m sure one of the moderators will kindly remove it.

Tom

Reply | Quote

Thanks Tom! Looks like a lot of the crew from the element k jounals forum. I wonder what ever happened to that forum (I was JoeK on that forum). The last time I tried to connect I couldn’t.

Reply | Quote

It is. Jim Hare was nice enough to put together the site and contacted as many of us as he could.

If Element K had given us some idea of what they planned, we could have had a better transition. Their loss.

Hope to see you over there sometime, Joe, er, ah, Paul.

Tom

Reply | Quote

Good old Jim. Wow, you mean they actually planned that debacle? Ooops, getting off topic here. C’ya

Reply | Quote

On the contrary, feel free to post links whenever you need to … as long as they don’t violate Rule 8 or Rule 18. It’s only posting copyrighted material or links to inappropriate or malicious sites that will earn you from the moderators.

Reply | Quote

There are other ways to do this as well if you do not want to use send keys and the commands at startup. The below code also disables other features as well.

Sub SetStartupPropertiesNone()
Const DB_Text As Long = 10
Const DB_Boolean As Long = 1
ChangeProperty “StartupShowDBWindow”, DB_Boolean, False
ChangeProperty “StartupShowStatusBar”, DB_Boolean, False
ChangeProperty “AllowBuiltinToolbars”, DB_Boolean, False
ChangeProperty “AllowFullMenus”, DB_Boolean, False
ChangeProperty “AllowBreakIntoCode”, DB_Boolean, False
ChangeProperty “AllowSpecialKeys”, DB_Boolean, False
ChangeProperty “AllowBypassKey”, DB_Boolean, False

End Sub

I use this routine to essentially allow users to have full read – write rights to all objects, however, don’t give them the ability to get to objects to do anything. They need full access to run pre-set queries that modify data in tables. The database is also saved as an .MDE with a top level password… however, I digress.

Actually, It is quite easy to re-establish the shift bypass in a database if it has been disabled unless you change the object itself. Microsoft explains how to do this in one of its white papers on security.

As Hans stated, a user could still import the objects to another database……

Reply | Quote