ULS on a split DB

  • Thread starter Thread starter UsenetUser
  • Start date Start date
U

UsenetUser

I'm a little confused about where to apply ULS on a split db.

Say I have a Data Entry group that I want to restrict to inserting
records only on a table. What permissions do I assign the group, the
FE query, and the BE table?

Also, is there a way to create a MDW file in Access 2007?

Thanks.
 
You can give the Data Entry group Insert Data permission on the FE
query. That and at least open permission on the FE Database Object and
open permission on the form based on your query, and open permission on
the BE Database Object. Save this query with the RWOP (run with owner
permission) property set to Owner and that's all they'd need.

You can only create a MDW file in 2007 if you are using the mdb file
format. If you use the accdb format, then security is not available.

Joan Wild
 
Hi Joan,

Thanks for the reply.

Who owns the query in this example - the person/group that created it
or the Data Entry group?

I don't see where (or perhaps don't understand how) to create the mdw
file in Access 2007. I understand the db itself has to be mdb.
 
The person who created the query is the owner. When you set the query
to RWOP, then users who run the query will do so as though the owner
were running it - more info at www.jmwild.com/RWOP.htm

I believe you need to start the workgroup administrator via code (hit
Ctrl-G and then...)

DoCmd.RunCommand acCmdWorkgroupAdministrator

Joan Wild
Be the kind of person your dog thinks you are.
 
Joan Wild
Be the kind of person your dog thinks you are.

My 9 dogs think I am a gruff old guy that does not feed them nearly
enough, hogging all the good stuff like fried chicken for myself, gets
unreasonably upset when they steal food from the kitchen table the
moment my back is turned, and torments them with vaccination
injections at the vet's!

Back to business: I guess I do not understand the value of RWOP
queries (or query permissions in general) to control permissons, over
setting permissions on the tables themselves. Any thoughts on that?

Thanks.
 
UsenetUser said:
Back to business: I guess I do not understand the value of RWOP
queries (or query permissions in general) to control permissons, over
setting permissions on the tables themselves. Any thoughts on that?

Have a read of the FAQ on ULS from MS, there's a link to it on my web site.
Everything you need to know about ULS is in there and none of it is waffle.

Keith.
www.keithwilby.co.uk
 
UsenetUser said:
My 9 dogs think I am a gruff old guy that does not feed them nearly
enough, hogging all the good stuff like fried chicken for myself, gets
unreasonably upset when they steal food from the kitchen table the
moment my back is turned, and torments them with vaccination
injections at the vet's!

Yeah but I bet they wag their tails off when they see you - you're a god
to them.
Back to business: I guess I do not understand the value of RWOP
queries (or query permissions in general) to control permissons, over
setting permissions on the tables themselves. Any thoughts on that?

With RWOP queries you don't need to give the users any permissions on
the tables at all - so therefore they can't even open the tables
directly - you can limit the records they see in a query using criteria.

The users though, need some kind of permissions in order to
add/delete/update data in those tables. 'Run with owner permissions'
queries allow them to do that. It means, when the users runs the query
it does so 'as though the query owner runs it'. Since the query owner
presumably has permissions on the tables, then the query is able to run
against those tables. You need to set the permissions on the query that
you want the users to have. So the query owner may have
insert/update/delete permissions on the tables, but that doesn't mean
that the user running the query will have those same permissions. You
need to set permissions on the *query* to dictate what they can do. So
you might give them update permission on the query. Even though the
owner has add/delete/update permission on the tables, the user will only
be limited to update because that is the permission they have on the
query they are running.
 
Have a read of the FAQ on ULS from MS, there's a link to it on my web site.
Everything you need to know about ULS is in there and none of it is waffle.

Keith.
www.keithwilby.co.uk

Did that several times, Keith, and worked through some examples before
posting. I did not see anything in there on why controlling
permissions is better through queries than directly on the tables
(where it has to be adjusted in any case). It seems like a pretty
simple question.
 
Yeah but I bet they wag their tails off when they see you - you're a god
to them.

Sure. I forgive them for stealing my food and (I think) they forgive
me for the injections. I even forgive the one that bites me every time
I have to hold her mouth closed for the vet to do her thing. Heck, us
gods have to be magnanimous!
With RWOP queries you don't need to give the users any permissions on
the tables at all - so therefore they can't even open the tables
directly - you can limit the records they see in a query using criteria.

The users though, need some kind of permissions in order to
add/delete/update data in those tables. 'Run with owner permissions'
queries allow them to do that. It means, when the users runs the query
it does so 'as though the query owner runs it'. Since the query owner
presumably has permissions on the tables, then the query is able to run
against those tables. You need to set the permissions on the query that
you want the users to have. So the query owner may have
insert/update/delete permissions on the tables, but that doesn't mean
that the user running the query will have those same permissions. You
need to set permissions on the *query* to dictate what they can do. So
you might give them update permission on the query. Even though the
owner has add/delete/update permission on the tables, the user will only
be limited to update because that is the permission they have on the
query they are running.

Thanks for your patience. I do believe I got it now. This is where I
was hung up: "you don't need to give the users any permissions on
the tables at all"
 
I believe you need to start the workgroup administrator via code (hit
Ctrl-G and then...)

DoCmd.RunCommand acCmdWorkgroupAdministrator

OK, but what about actually administering security once the mdw file
is created- setting permissions, group memberships, etc. I can't seem
to do much by opening the file directly.

Thanks.
 
Back
Top