Very Computer

Hi Folks-

I'm upsizing an Access MDB to an Access ADP, and I just found out that
ADPs (and ADEs) do not have the Database Password feature that MDBs and
MDEs do.  This database password feature was used in the original front
end here to keep users from sucking out raw data from the database by
simply importing tables from the front end.  This is explained below.
Now how can I keep users from importing tables from the ADP/ADE front
end?

In the environment where the DB is used, it is critical that users only
be allowed to view data THROUGH THE FRONT END FORMS.  For example,
salespeople are only allowed to see their own customers.  The front end
forms programatically display only the customers of the user who signed
into the front end's own Sign In form.  To prevent salespeople from
poaching each other's customer contacts, there is a DB Password on the
actual front end MDE.  The users do not know the DB Password, and
therefore cannot extract raw table data by importing the MDE's tables
into a new Access file.

In order to open up the actual front end, the user opens up another,
different MDE (the "Launcher") that has NO TABLES, whose only function
is to programatically automatically open up the actual front end MDE.
The DB Password of the real front end is written inside the code of the
"Launcher" MDE, and the code of the Launcher MDE is, of course,
inaccessible.

So until now that system has worked really well.  Yeah, I know the
Access DB password is supposed to be fairly easy to hack one's way into,
but the security level was really sufficient considering the computing
abilities of the users here.  But releasing a password-less ADE file
that users can easily pull all the raw data out of by simply importing
the tables is NOT enough security.

Does anyone know a way to stop users from pulling raw data out of an ADE
file by simply importing its tables into a new Access file?  Thank you
for any insight.

-Paul

Home:  www.gis.net/~winglift

Hi Paul,
First, you need to prevent access to the tables (no select permissions).
Then you can define a view that will select only the rows corresponding to
the salesman
who is currently logged on.
Select * From <Table Name>
Where salesman = SYSTEM_USER
assuming of course, that in the above table there is a field called
"salesman" which gets filled
automatically with the (SYSTEM_USER) value when the salesman enters a new
customer.

Then you give select permission on the view only.
This way, each salesman will only see whatever customers he has entered
himself.

HTH

Quote:> Hi Folks-

> I'm upsizing an Access MDB to an Access ADP, and I just found out that
> ADPs (and ADEs) do not have the Database Password feature that MDBs and
> MDEs do.  This database password feature was used in the original front
> end here to keep users from sucking out raw data from the database by
> simply importing tables from the front end.  This is explained below.
> Now how can I keep users from importing tables from the ADP/ADE front
> end?

> In the environment where the DB is used, it is critical that users only
> be allowed to view data THROUGH THE FRONT END FORMS.  For example,
> salespeople are only allowed to see their own customers.  The front end
> forms programatically display only the customers of the user who signed
> into the front end's own Sign In form.  To prevent salespeople from
> poaching each other's customer contacts, there is a DB Password on the
> actual front end MDE.  The users do not know the DB Password, and
> therefore cannot extract raw table data by importing the MDE's tables
> into a new Access file.

> In order to open up the actual front end, the user opens up another,
> different MDE (the "Launcher") that has NO TABLES, whose only function
> is to programatically automatically open up the actual front end MDE.
> The DB Password of the real front end is written inside the code of the
> "Launcher" MDE, and the code of the Launcher MDE is, of course,
> inaccessible.

> So until now that system has worked really well.  Yeah, I know the
> Access DB password is supposed to be fairly easy to hack one's way into,
> but the security level was really sufficient considering the computing
> abilities of the users here.  But releasing a password-less ADE file
> that users can easily pull all the raw data out of by simply importing
> the tables is NOT enough security.

> Does anyone know a way to stop users from pulling raw data out of an ADE
> file by simply importing its tables into a new Access file?  Thank you
> for any insight.

> -Paul

> Home:  www.gis.net/~winglift

Thank you, Mohamad!

-Paul