Secure all objects so that design cannot be seen! 2

[blurworld]

Hi

How can i secure all objects in an access database so that the design view cannot be seen by any users (except an administrator) but i don't want users to log-in
- i want everyone to have the same access to objects otherwise( as i am limiting access by using different switchboards).

Thanx
-Martin

 

[TheWildHare]

1) disable the database window
2) control exiting/closings form by turning off borders (and hence the close/minimize/restore buttons)
3) make sure you exit access when you leave the main menu.
4) make sure you use a startup form and an autoexec macro
5) hide objects, so even if a user somehow finds the database window, they don't see anything...

Any object can be 'hidden' by prefacing it with USYS as the first four characters of the name. Of course, if you users are swift enough to do a TOOLS/OPTIONS/VIEW and Show the Hidden/system objects, then there's not much you can do from there.

The other option of course is to make an MDE file of compiled objects, but this has its own set of ramifications.

Jim

 

[JimHorton]

Martin,
An easier way is to use Access' Security, then you don't need to worry about hiding windows, disableing borders, using macros, hiding objects etc, etc--that is such a mess that you will surely leave a hole somewhere and drive yourself batty just trying to implement it.

Get the faq on Security (I think there's one here, if not MSKB has a whitepaper on it). Once you fully understand security, you can comfortably have your system out there without the aforementioned mess, and without the constraints of mde files.
--Jim

 

[Dany527]

On your main form, create a command button, set format properties
Transparent Yes, visible Yes (This is your secret Button) on the doubleClick event
of the Command Button enter the following code;

On Error GoTo Err_cmdEnterSetUp_DblClick

If InputBox("Enter Design view Password", "password&quot = "modview" Then
SetStartupProperties
Else
MsgBox "YOUR PASSWORD WAS INCORRECT Access to design mode is
denied!", vbCritical, "WARNING!"
SetStartupPropertiesNoBypass
End If
Exit_cmdEnterSetUp_DblClick:
Exit Sub

Err_cmdEnterSetUp_DblClick:
MsgBox err.Description
Resume Exit_cmdEnterSetUp_DblClick



This code when passord is Incorrect disable the Database Window, the F 11 Key as well as the Shift key. I enter the correct password when I need to work on the dB and enter NO when I want to put It back to protection mode. the code takes effect the next time the dB is Opened. So far, no one has has been capable of breaking this code so I Can sleep at night...

 

[TheWildHare]

Martin, I agree with JimHorton, using Access Security IS the better way to go - and it's not all that difficult. I was going on your statement that you don't want users to log in, which they would do using workgroup security. I'd really suggest you check it out and seriously consider using it. There's also a whitepaper written by someone else that I have posted up on my site

http://www.jmhare.com/dbsecurity.htm

Good luck

Jim

 

[Lavey]

Hi,

I used to have all my database unsecured, but now use Access security... it makes life a lot easier to controlwho sees and does what.

It was a lot easier than it looks, I agree with the Jim's, read up and give it a go...the users will geet used to it like any other change
Honest guv, i didn't do it !

 

[pdldavis]

Dany527, I have a similar situation with a couple db's as blurworld and you're reply sounds like the answer I'm looking for.
I've been trying your cmd button code I have not had any luck with the 'setstartupproperties' and don't see it listed in the help section.
Could you clarify what 'setstartupproperties' is and how to use it?

Thanks, Dan

 

[JimHorton]

blur,
Actually, users don't need to log in with Access security set up. You can do this in a few ways. The easiest is to give general permissions--such as Read-only, to most forms and data, maybe Insert permissions to data they'd be entering--to the Admin user. Now, there's no login, and the Admin user can't read design or update any data you don't want them to.

Another way is to set specific permission to specific groups and/or users, then set up a shortcut using the /user "myuser" switch.

You develop the db under your developer user, who owns all objects. This user must *not* exist in the .mdw file that is on each client machine or the shared on on the network, if you use a shared .mdw. This is due to the fact that there are password cracking tools out there that can extract user/passwords from the .mdw. If the user isn't there, it can't be cracked. If you need to make spot-changes on a users machine (or debug), then create the developer user there, and delete it immediately after you're done with the debugging.
--Jim