I have a 2000 database that users ULS for restricting access to forms and
reports.

What is the best, or any, solution for restricting access to forms and
reports in 2007 which doesn't support ULS?

"JeffP" <no-reply (AT) asken (DOT) com.au> wrote:

A2007 still supports ULS in MDB file format. You do give up the user of the new
field types such as multi valued fields which are only available in ACCDB file
format.

T
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

On Wed, 26 May 2010 09:44:25 +1000, "JeffP" <no-reply (AT) asken (DOT) com.au>
wrote:

If you are on a domain, you can use the techniques discussed here:
http://www.accesssecurityblog.com/po...Directory.aspx

-Tom.
Microsoft Access MVP

Not on a domain Tom. Only on a local network.

"Tom van Stiphout" <tom7744.no.spam (AT) cox (DOT) net> wrote

It is already a 2007 format database Tony. No going back.

"Tony Toews [MVP]" <ttoews (AT) telusplanet (DOT) net> wrote

"JeffP" <no-reply (AT) asken (DOT) com.au> wrote:

Are you using the new features though? If not sure you can go back.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

Not really at the moment, but the clients IT guys stipulated 2007 format so
no going back. And in this case I don't think reverting back to a MDB format
is a good solution.

They will move with the versions so it will only be a matter of time.

"Tony Toews [MVP]" <ttoews (AT) telusplanet (DOT) net> wrote

You can use the same techniques, using local groups,
the only problem is that local groups aren't shared to
other computers. (the sharing is what the Active part
of Active Directory is).
On a single computer you wouldn't have to do that -
the groups are there, it's just not well known. They
are the local version of domain groups.

A user-level mdb "workgroup" is just a database
with a table listing groups and a table listing members.
The only magic about it is the ID's can be associated
with Forms and Tables in an MDB database. Since
Tom's techniques don't depend on that magic, Tom's
techniques, (although not the directory lookup code)
can be used with your any database, not just an AD
or LD database. That is, you can re-write his code to
use groups and users maintained in a 2007 database.

(david)


"JeffP" <no-reply (AT) asken (DOT) com.au> wrote

"JeffP" <no-reply (AT) asken (DOT) com.au> wrote in
news:0rmdndL1_OgaAmHWnZ2dnUVZ_tCdnZ2d (AT) westnet (DOT) com.au:

MDB is a native format for A2007. It's just not the *new* format.

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

Tom van Stiphout <tom7744.no.spam (AT) cox (DOT) net> wrote in
news:u3uov51sun9g2sh13lge6sog42qubeh286 (AT) 4ax (DOT) com:

Two comments on that:

1. why if it's a domain logon does it matter what the setup on the
workstation is? Aren't you getting the information from the domain
controller?

2. why use AD for simply working with NTFS security groups -- you
can already get group membership information without needing to
interface with AD. The only advantage I can see to AD is if your
domain uses Organizational Units. In 2004 I was in a situation where
I easily could have used Organization Units to control access to
data in an app that was hosted on Windows Terminal Server. But at
the time, nobody had done the work with AD code to make it easy in
Access.

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