By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,704 Members | 1,867 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,704 IT Pros & Developers. It's quick & easy.

Access 2003: Thinking about going multiuser with user security,...

P: n/a
PW
Any suggestions, knowledge base articles, books? We are not going to
go field level but now we have a couple clients that would like to
limit what employees can see of our application (forms and reports). I
guess we would need to create a database containing user names and
what forms and reports they can access (and then probably going to
have to be responsible for that database too <g>.?

Thanks,

-paulw
Dec 7 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
PW
On Thu, 06 Dec 2007 20:39:25 -0700, PW
<pa**********************@removehotmail.comwrote :
>Any suggestions, knowledge base articles, books? We are not going to
go field level but now we have a couple clients that would like to
limit what employees can see of our application (forms and reports). I
guess we would need to create a database containing user names and
what forms and reports they can access (and then probably going to
have to be responsible for that database too <g>.?

Thanks,

-paulw

We most likely will also want to log who made what changes to what
record and when.
Dec 7 '07 #2

P: n/a

"PW" <pa**********************@removehotmail.comwrote in message
news:jq********************************@4ax.com...
Any suggestions, knowledge base articles, books? We are not going to
go field level but now we have a couple clients that would like to
limit what employees can see of our application (forms and reports). I
guess we would need to create a database containing user names and
what forms and reports they can access (and then probably going to
have to be responsible for that database too <g>.?
Any self-implemented security is, at best, "security lite", and more
commonly, "security not at all" because it can be so easily defeated by
someone who knows Access even moderately well. Even though it is "fallible"
(as is, to a great extent, any security system that a penetrator can get
his/her hands on), Access' user/group level security is much less easy to
break. That is still available in Access 2003, and even in Access 2007 for
MDB / MDE databases. It is not available for the Access 2007-specific ACCDB
databases.

Larry Linson
Microsoft Access MVP
Dec 7 '07 #3

P: n/a
Fester Bestertester previously wrote:
5. Read through some tutorials about User Level Security and walk
through the ULS Wizard a bunch of times. Then do some more reading and
research. Creating a workgroup security file that's specific to one
particular application, and does not affect all Access sessions on a
machine, is a little tricky.
Here's a good MS FAQ page on creating a security file that is specific
to a particular database or application (I believe this also applies in
Access 2003):

http://support.microsoft.com/default...#_Toc493299688
Dec 7 '07 #4

P: n/a
lyle fairfield wrote:
Many developers do almost none of the above, with the exception of
splitting their applications.
I am one of them.
Hmmm...raises an interesting point for discussion. Seems that at the
very least I'd want to deploy the application with some kind of failsafe
mechanism, so that if the back end data file got moved, the front end
had some reasonably elegant way of restoring the links without requiring
developer intervention. At the most, it would require 1 minute of time
from a system administrator who knew the correct path for the backend
and could point the app there. That's probably why the Verify Links
modules have been adopted so widely. Why re-invent the wheel when it's
already out there?

As far as the other stuff goes, setting up a specific security file for
that app might make for an inconvenience for the users, since they have
to remember a separate username and password for the application. But I
can't imagine allowing users to go in and monkey around with the design
of the app. So it seems that, again at the very least, you'd want to
turn off all or most of the startup options.

Also, one other caveat. I recall seeing a lot of issues a few years back
when developers tried to deploy a split front/back database, but where
there were multiple versions of Access installed on the various
workstations, especially 97 vs. 2000. What I learned from that was that,
as a general rule, it's a good idea to migrate everybody altogether from
one version of Office to the next before deploying an application. Just
to be on the safe side.

Have you really deployed split apps with no security and no front
end/back end verification and no startup options turned off? No troubles
with that?

Dec 7 '07 #5

P: n/a
PW <pa**********************@removehotmail.comwrote :
>We most likely will also want to log who made what changes to what
record and when.
There's a simple example at
ACC2000: How to Create an Audit Trail of Record Changes in a Form
http://support.microsoft.com/default...;en-us;Q197592

Audit Trail - Log changes at the record level at:
http://allenbrowne.com/AppAudit.html
The article addresses edits, inserts, and deletes for a form and subform.

Modules: Maintain a history of changes
http://www.mvps.org/access/modules/mdl0021.htm
The History Table routine is designed to write history records that track the changes
made to fields in one or more tables.

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/
Dec 8 '07 #6

P: n/a
PW
On Sat, 08 Dec 2007 01:18:51 GMT, "Tony Toews [MVP]"
<tt****@telusplanet.netwrote:
>PW <pa**********************@removehotmail.comwrote :
>>We most likely will also want to log who made what changes to what
record and when.

There's a simple example at
ACC2000: How to Create an Audit Trail of Record Changes in a Form
http://support.microsoft.com/default...;en-us;Q197592

Audit Trail - Log changes at the record level at:
http://allenbrowne.com/AppAudit.html
The article addresses edits, inserts, and deletes for a form and subform.

Modules: Maintain a history of changes
http://www.mvps.org/access/modules/mdl0021.htm
The History Table routine is designed to write history records that track the changes
made to fields in one or more tables.

Tony

Thanks Tony!

-paulw
Dec 8 '07 #7

P: n/a
Tony Toews [MVP] wrote:
Audit Trail - Log changes at the record level at:
http://allenbrowne.com/AppAudit.html
The article addresses edits, inserts, and deletes for a form and subform.
This is really nice, I just tested it in an Access 2003 split app/db and
it works great. Thanks to Alan!
Dec 8 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.