Using Runtime version or /runtime command switch) as Security Meas

[dch3]

I *really* want to avoid implementing Access security. Given that I'm the
only person developing in Access in the office where I'm based, I'm
entertaining the idea of only installing Access runtime if Access needs to be
installed at all. I've already got several roadblocks in place - hide DB
window, custom Menu w/limited commands, *.MDE version coming soon, all access
via a Main Form displayed at startup and redisplayed when a form closes. My
thought with the runtime route was to present a further roadblock that would
prevent users from opening up the back end and deleting data or other what
not either from directly opening the *.MDB file or creating a new *.MDB file
and linking in.

Thoughts?

 

[Chris O'C via AccessMonster.com]

Any odbc compliant client app can update, delete and add to the data in the
mdb or mde file if you don't implement either Access user level security or
assign a db password. Both of those aren't foolproof, but they'll raise the
bar as an obstacle for getting at your data. Most people can't figure out
how to get past either of those, even though they can download the tools from
the internet if they dared to look for them.

Chris
Microsoft MVP

 

[Chris O''Neill]

I understand your hesitance, as implementing Access security can be daunting
(to say the least). I've started implementing security in m app and it's had
me banging my head against the wall a couple of times.

Having said that, the *only* way (AFIAK) to keep people out of your BE MDB
is to use Access security to lock it down. If you want to do that and keep
the security transparent to the users, maybe check this out:

Security without a Login:

http://www.jmwild.com/SecureNoLogin.htm

I'm not sure if that will be helpful to you, but it's worth a look.
Finally, the folks over at the Access Security forum have been *very* helpful
to you. You might want to wander through that forum and see what's helpful
to you. Here's the link for that:

http://www.microsoft.com/communitie...ault.aspx?dg=microsoft.public.access.security

Hope that's help. Good luck with your quest...

Regards, Chris

 

[dch3]

Given the user pool, and that we're a relatively small group, anyone capable
figuring out how to use an alternate ODBC client would stand out. Given that
we're a preferred provider TO Microsoft, there's a high probability that we'd
never have any other ODBC client out there to begin with.

In terms of locking down Access, (and the paranoia over locking myself out),
I've used the /command switch to pass specific values into my startup
routines. Given how I've set up my Main Menu, I'll probably setup code with
causes my startup to execute a Main Menu function if present, (one of the
functions is to Show the Database Window) which would have other benefits as
well - such as opening the database to a specific form (if the user is
authorized).

 

[Tony Toews [MVP]]

I *really* want to avoid implementing Access security. Given that I'm the
only person developing in Access in the office where I'm based, I'm
entertaining the idea of only installing Access runtime if Access needs to be
installed at all. I've already got several roadblocks in place - hide DB
window, custom Menu w/limited commands, *.MDE version coming soon, all access
via a Main Form displayed at startup and redisplayed when a form closes. My
thought with the runtime route was to present a further roadblock that would
prevent users from opening up the back end and deleting data or other what
not either from directly opening the *.MDB file or creating a new *.MDB file
and linking in.

Also keep in mind that anyone can take a copy of the BE MDB file home
with them and open it in a retail version of Access.

If your data requires that much security then I'd consider SQL Server
in a computer behind a locked door. What makes SQL Server so
secure is that the only way to get to the data, unless you're logged
into the server as administrator, is via SQL Server running on that
box. Although this explanation is rather simplified.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/