There are a few things you can do to throw up road blocks, but the
determined can get past them:

1. Put the backend in a hidden share i.e. \\share\folder$ rather than
\\share\folder

2. Put a database password on the backend (you'll then need to
delete/recreate the links in the frontend and then redistribute it)

3. Add an autoexec macro to the backend which
a - msgbox to tell the user to use the frontend
b - quit action to close the mdb

4. Disable the shiftkey bypass in the backend so they can't bypass the
autoexec.

Joan Wild



ErikFM via AccessMonster.com wrote:
> Hi everyone,
>
> I have a question regarding securing a backend Access file.
>
> Currently, the backend is residing on a shared network folder, so that the
> users who have the front-end on their PCs can have access to the data.
>
> What I am wondering is if there is someway to password protect the backend
> file, or the folder it's sitting in, so that no one can go into the tables
> and make changes (or accidently delete) the tables in it.
>
> But, I also want to ensure that the front-end users won't be blocked from
> access to the data.
>
> Any thoughts? I've searched the forums here, but am still a little confused
> as to what will be the best course of action.
>
> Thanks!
>

Joan Wild <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 4. Disable the shiftkey bypass in the backend so they can't bypass
> the autoexec.

....unless, of course, they know how to re-enable it in code.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David W. Fenton wrote:
> Joan Wild <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
>> 4. Disable the shiftkey bypass in the backend so they can't bypass
>> the autoexec.
>
> ....unless, of course, they know how to re-enable it in code.
>

One part you snipped:
"There are a few things you can do to throw up road blocks, but the
determined can get past them"

so yes, of course, a road block is only just that

Joan Wild

For a hundred users, it may take a day, or slightly longer, to set up
security. I'd create a spreadsheet with all the users and groups and use
that to create a set of users and groups in a database. Access 2003 has a
security manager that makes the job much easier, so you may want to build
the database on that. If you want to keep everyone out of the back end, you
have only 1 choice, and that is to use: WITH OWNERACCESS OPTION queries, you
can do that by turning on Owner in Options, and copying and pasting the SQL
in the new query formed. Then remove all permission for everyone except the
owner on the backend.

Download the references that I mentioned in my earlier post. They are
invaluable.

If you follow the instruction in the Security FAQ precisely, you won't have
any significant problems.

If the back end is secure, they can import the file, it's still secure and
they don't have permissions except through the front-end. If you really
think that users will attempt to steal or destroy data, you need to rethink
whether or not you want to keep those users. Access, like anything else
isn't 100% secure. Other databases, like SQL-Server do have more robust
security, and you may want to investigate them. There are free versions of
SQL-Server.

Back up the secure files, the same way you backup and restore any other file
on your computer. Do restore every now and then to make sure your backup
plan works the way you expect.

One last thing. The only really safe ways to use Access over a VPN are to
either create an ASP(.NET) front-end, or to use terminal services. There is
too great a chance of dropping a connection and corrupting a file, and other
way.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"ErikFM via AccessMonster.com" <u57373@uwe> wrote in message
news:a25a3f46cb27e@uwe...
> Thank you all for your excellent advice. This truly is the best Access
> forum
> on the web.
>
> A fellow analyst uses this solution for his databases:
>
> 1. An Excel file which requests a password. The correct password turns on
> the
> Enable ByPass setting the MDB file.
>
> 2. Creating the AutoExec close database macro in the backend.
>
>
> One thing though... with each of these solutions, how can I be sure that
> my
> front-end users will still have access to the back-end data?
>
> Also, if I have 100+ users (Account Managers across several branches in a
> VPN/WAN), is User-Level security a pain to set up?
>
> And finally... has anyone ever figured out how to prevent Access users
> from
> just importing everything into another database? Although, that might not
> be
> very desireable, in case the database gets corrupted.
>
> Thanks again! You guys are great.
>
> I think I may search for some low-level questions to answer, just to 'pay
> it
> forward'. =)
>
> --
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/For...urity/201001/1
>

"ErikFM via AccessMonster.com" <u57373@uwe> wrote in
news:a25a3f46cb27e@uwe:

> A fellow analyst uses this solution for his databases:
>
> 1. An Excel file which requests a password. The correct password
> turns on the Enable ByPass setting the MDB file.
>
> 2. Creating the AutoExec close database macro in the backend.
>
> One thing though... with each of these solutions, how can I be
> sure that my front-end users will still have access to the
> back-end data?

The bypass keys are relevant only to opening a file in the Access
user interface. Your back end should be used by your users only via
your front end, so if you turn of the bypass keys in the back end,
users won't be able to view the data by opening the back end in
Access.

But it has no effect on retrieving data from the back end via
Jet/ACE for use in your front end (or in any other application,
e.g., Excel).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Joan Wild <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

>
> David W. Fenton wrote:
>> Joan Wild <(E-Mail Removed)> wrote in
>> news:(E-Mail Removed):
>>
>>> 4. Disable the shiftkey bypass in the backend so they can't
>>> bypass the autoexec.
>>
>> ....unless, of course, they know how to re-enable it in code.
>>
>
> One part you snipped:
> "There are a few things you can do to throw up road blocks, but
> the determined can get past them"
>
> so yes, of course, a road block is only just that

I don't consider it a security measure, just something you do to
keep out the well-intentioned and incurious.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David W. Fenton wrote:
>
> I don't consider it a security measure, just something you do to
> keep out the well-intentioned and incurious.
>

Exactly

Joan Wild