Import limit problem?

[niclive]

Hi,
I want to prevent users from importing objects from my .mdb
file.However I do not want to create an mde file and I do not want to
use a database password.I have created my own security with VBA using
a table,logon form, and various global variables that limit users
access to specific forms.I have also disabled the shift bypass key.
But a user can import all my objects to a new database without any
problems and use my code and all objects freely.I want to prevent
that.Is there a way using VBA?any help will be much appreciated.
Thanks

 

[Douglas J. Steele]

You've already eliminated all of the possible ways to prevent copying.

Home-grown security methods are seldom effective (in fact, saying "never
effective" wouldn't be that much of a stretch)

 

[Scott McDaniel]

Hi,
I want to prevent users from importing objects from my .mdb
file.However I do not want to create an mde file and I do not want to
use a database password.I have created my own security with VBA using
a table,logon form, and various global variables that limit users
access to specific forms.I have also disabled the shift bypass key.
But a user can import all my objects to a new database without any
problems and use my code and all objects freely.I want to prevent
that.Is there a way using VBA?any help will be much appreciated.
Thanks

In short, no, there is no way to prevent this given the parameters you specify.

Why do you not want to create an .mde file? Users cannot export/import objects (forms, reports, modules) from an .mde
file, so that would take care of those items. As far as Tables and Queries, you'd have to implement User Level Security
and manipulate permissions such that users wouldn't be able to gain access directly to the tables (i.e. use RWOP
queries, and then remove all access to the tables). Users could still import queries, perhaps, but it wouldn't do them
much good.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[unhinged]

Garry Robinson details a method for doing this using a workgroup file
- create a new workgroup file, create a user and add that user to the
"Admins" group. Then remove the "admin" user from the "Admins" group.
Log in as the only remaining admin user and import all of your objects
from your existing mdb file - this results in all of the objects now
being owned by your admin user. The next step is to make sure that the
"Users" group only has read permissions on your forms and queries.
After that, distribute your solution with a workgroup file that has
the default "admin" account removed from the "Admins" group, and set
things up so that users can only launch your solution using that
workgroup file. DO NOT use the same workgroup file that you use to
develop as this will include your developer account and allow an
unscrupulous user to hack the password from it.

Since this post is only from memory, I strongly recommend that you
read Garry's book, "Real World Microsoft Access Database Protection
and Security" from Apress, so that you cover all the angles. There are
weaknesses to this method, but I think it's the strongest possible
solution without going to an mde format.

 

[niclive]

Garry Robinson details a method for doing this using a workgroup file
- create a new workgroup file, create a user and add that user to the
"Admins" group. Then remove the "admin" user from the "Admins" group.
Log in as the only remaining admin user and import all of your objects
from your existing mdb file - this results in all of the objects now
being owned by your admin user. The next step is to make sure that the
"Users" group only has read permissions on your forms and queries.
After that, distribute your solution with a workgroup file that has
the default "admin" account removed from the "Admins" group, and set
things up so that users can only launch your solution using that
workgroup file. DO NOT use the same workgroup file that you use to
develop as this will include your developer account and allow an
unscrupulous user to hack the password from it.

Since this post is only from memory, I strongly recommend that you
read Garry's book, "Real World Microsoft Access Database Protection
and Security" from Apress, so that you cover all the angles. There are
weaknesses to this method, but I think it's the strongest possible
solution without going to an mde format.

Thanks.This works okay.But I should just create the .mde.
regards