Access: Protect data in tables from copy and export...

[ANSWER]

I have mdb. file who is going to be mde

Is there way to protect data in my tables from copy of export functions.

Thanks

 

[Adrian Jansen]

You have to do a fair bit of work to protect a database. First get and read
the Access Security FAQ, several times. Once you have the database secure,
and the tables secured so that no users can directly read them, then you can
hide the Access standard menus so only the functions you want users to have
are available, then you can be reasonably sure that users cannot easily
export your data. But in principle any user can still do this. After all
you have to trust your authorised users, dont you ?

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

 

[TC]

But in principle any user can still do this.

Not really. The forms, reports & other code could all be based on RWOP
queries. The owner of the RWOP queries could be the only user who had any
access to the tables. Then, if that user had an unknown password, no-one can
log-on directly as that user. So, the others users can happily use the
forms, reports & other code, but they can not access the tables directly -
for import, export, or anything else.

Cheers,
TC

 

[Adrian Jansen]

True, as long as you take away all other users rights to create or modify a
query, form or report.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

 

[TC]

Not sure what you're getting at there. Do you mean, for them to create those
objects in the db containing the RWOP queries? Or to create them in some
other db, linking to the RWOP queries?

Cheers,
TC

 

[JustMe]

I am still totally amaized at the Companys that hire people and try to lock
the useres out of the very data thier trying to use to get answers. I use to
work on the Paradox Up and Running line and customers would call in wanting
to know "How can I lock users out of the database and still let them have
access to using the database".
The answer is YOU CAN't".
Either you have trust in the people with the data or you don't. In which
case "Why did you hire them?"
Think about it!

 

[Adrian Jansen]

Sorry, I missed a bit here.

In reply to TC, if I have a database, and a user with say full read/write
permissions on queries in the database, but no permissions directly on the
tables, then I have found that they can create a query on a table, and read
the data in it. The only way to stop that is to deny permissions to create
a query. Maybe I still havent got the database fully secure.

And in answer to Just Me, the intention is not so much to lock people out of
the data, but more to restrict them to the forms and reports, where its much
more difficult to accidentally screw up a huge pile of data.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

 

[TC]

My personal view is this. If the users created the data (eg. by data entry),
they >own< that data, so it is not acceptable to lock them out of it
permanently. But, the developer has a legitimate need to ensure that the
user does not alter the data tables directly, bypassing the application
software. Sometime, those two conflicting needs are hard to meet.

Cheers,
TC

 

[TC]

Adrian, I don't follow you there. If a user has "no permissions directly on
the tables", they definitely should not be able to create & run a query on
those tables, no?

Cheers,
TC

 

[Adrian Jansen]

Yes, you are correct, as usual.

Somewhere in playing around with the security during testing, I had set read
permissions on the tables for the group I was adding, as well, and that
allowed users in that group to create queries on them. When I removed that
permission, the user could no longer get access, apart from using a RWOP
query owned by someone else.

Fortunately this was only a test version. The production release is secure.

Access security is complex !

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

 

[test]

(snip)

Yes, you are correct, as usual.

I feel my hat size growing ...

TC