Protect my database from dangerous code of another database

[ofdeclast]

Anyone can enable a database bypass key from another database...

How can I protect dangerous code from other database..........

[ItsMe]

The first thing is to have security on the network. So Active Directory can help a lot with that. Of course network security is a large topic.

As for the Access file, itself, if you are worried about someone opening it and tampering with it, you should convert it to an accde. Also, you should use VBA code to hide objects like tables and queries.

Before you convert it to accde, use VBA to affect the Hidden property of these objects. Also, it is not a bad idea to do this to the sys tables. So, I would iterate the tables collection and adjust the Hidden = True.

[Micron]

Some would say that at their basic level, some systems are more secure than Access is at its most complex. Perhaps you should post what it is that you're concerned could be affected should someone override the shift bypass property. If, as suggested, your front end is already converted, there's not much that can be done to it code-wise. It could exposed linked table paths, but I always link tables with a password so they cannot be opened by anyone who doesn't know the password. When you get down to it, robust Access security is a compilation of efforts within Access as well as other means such as directory permissions that have been created properly.

[ofdeclast]

I did as above instructions. But when i gave password to my backend.accdb file then my front end get very slow to execute.

[Micron]

But when i gave password to my backend.accdb file then my front end get very slow to execute.

Not sure if you're referring to what I posted, because I did not say to "give a password" to a file, which I interpret to mean you password protected a file. I said I set a password when I link to the tables in the back end database file.

[Missinglinq]

...Perhaps you should post what it is that you're concerned could be affected should someone override the shift bypass property...

I think that this is the really important question, here! How you provide security depends largely on what you're protecting and who the likely interloper could be.

Linq ;0)>

[ofdeclast]

Actually I said about encrypted password from option menu to the back end. When I set password my front end get very slow.

[ofdeclast]

I am creating a MS Application for an organization. But I think couldn't have enough security for protecting it from them. Here is my first headache:
Sub EnableShiftKey()
Dim db As DAO.Database
Dim prp As DAO.Property
Set db = OpenDatabase ("\\PATH\TO\TARGET\DATABASE.MDB")
db.Properties.Delete "AllowBypassKey"
Set prp = db.CreateProperty("AllowBypassKey", dbBoolean, True, True)
db.Properties.Append prp
db.Properties.Refresh
Set prp = Nothing
Set db = Nothing
End Sub

[CJ_London]

as has been asked before - what are you trying to protect? and who from?

just some suggestions

code - convert to .accde/.mde - would solve your problem in post #8
direct access to tables - password protect back end, use accdb rather than mdb since mdb encryption is very easy to break
bypass key - disable bypass key, hide navigation windows and ribbon and disable keys to unhide
indirect access to tables and queries and discovery of password - do not use linked tables (password can be seen in linking data) but link as and when required using code - and ensure your password is not hard coded by calculated in the code
slow access to backend - maintain persistent connection, ensure path to backend is short, ensure efficient network, ensure system only brings through what it needs (think how web pages work). don't use forms/combos/listboxes which pull through entire tables and filter on form (the Excel mentality) - restate the rowsource to bring through what is requested, consider using sql server/mysql and stored procedures