Don't import tables 1

[EllieFant]

Short of password protecting a database (using database password under security) how do I protect my information in my database (mainly the tables since that is where sensitive information is stored) from being imported by someone.

The reason I ask is cause I want people to be able to use the database but don't want these same people to be able import the tables into another database so they can see information they don't have access too otherwise (such as social security numbers, employee numbers and etc).

I need to be able to do this in Access 97 since it is a work related database.

Thanks,
Ellie
**Using Access 97 at work**
**Using Access 2000 at home**

lena.wood@starband.net

 

[Fubear]

The only way would be some form of password security, either a default databse password, or user level security to limit what information people have access to.

I would advise on user level security, you can (i belieive) remove access to tables which hold sensitive data, but allow access to the views that are required to view them.

Exporting the view would be useless as it would not be able to view the table in another databse.

 

[EllieFant]

Thanks for the information. I am leary to try the user level passwords as I have locked myself totally out of Access trying to do that and it doesn't make our IT department very happy when they have to come and reinstall Access cause I have locked myself out.
Ellie
**Using Access 97 at work**
**Using Access 2000 at home**

lena.wood@starband.net

 

[telephoto]

This works for me.

Start with 2 folders, one you can open , and one everyone can open.

You have a copy of the full database in a folder you can open.

Make a databse "blank" in the other folder.

In your database design a query to select the fields you want others to be able to see, change it to a make table query and direct it to the other database in the shared folder. The data is continually refreshed each time you close a form (using a command button)in your copy of the data, because that runs a macro with the following steps:
setwarnings no
runcommand saverecord
openquery maketable
closeform (the one that's open)
setwarnings yes

The use of setwarnings no is to prevent Access advising you that it is about to delete the remote table before replacing it with a new copy.

Result is a completely separate database that no-one can use to get back at your confidential data.



telephoto
I've done 2 like this and both work fine.

 

[EllieFant]

The database is on a network drive that only the allowed employees are allowed to see. I am wanting to protect the database from those eyes that have access to the drive because it is their job to manage the networks (our IT department). I am in no way saying they would break into my database and "steal" the data, but in the department I now work for, we need to be able to take every step possible to protect our data.

Although this doesn't seem to be a solution to my problem however, it does present a solution to a coworkers problem on updating a different database from within a database.

Thanks for taking the time to answer my question. I was really hoping there was another way...but password protecting the database itself will have to do.

Thanks, Ellie
**Using Access 97 at work**
**Using Access 2000 at home**

lena.wood@starband.net

 

[GDGarth]

You need to implement user level security. The security in Access is pretty good - and it's not that hard after you figure it out.

There's a security FAQ - check it out and follow the instructions exactly.

 

[EllieFantHome]

The last time I tried to implement user level security I locked myself totally out of access. Our IT department had to come and re-install Access...to say the least, they were not happy with me :-( Kinda scares me to try it again.

I will check out the FAQ though...I will just warn them I am trying again.

Thanks for the help.

 

[Fubear]

As far as i remember, the workgroup file holds the list of valid logons while the databse holds the permissions.

What you do is create a new workgroup for your own use, and give your own account full access to the databse, then remove access to the tables for the admin login (but not the view which use the tables).

When a user comes to open the databse from the default workgroup file, they will auto login as admin, and wont be able to access the tables directly. In addition the security you implement will be transparent to the user, so you dont need to worry about login details for each user.

The only way to access the tables directly would be using your login from your custom workgroup file.