CreateGroup() needs restart for changes to take place

[Greg]

I am creating a new Group with CreateGroup method and
leting an existing user join it. Everything works fine and
the changes are reflected in the User/Group accounts
window but the user does not gain the extra permissions
the Group has, until I exit and restart the Application
(meaning that using "DoCmd.TransferDatabase acExport..."
he gets the error that he cannot read Design of the
object, while being a member of the Group he should and
also if I exit my code and try to view the design of the
object I get the no permission message).
He also gains the extra permissions if I go to the
User/Group accounts window and manually remove and add
again the Group to the User.
Exactly the same happens when I use the delete method to
remove the Group. The User keeps his extra permissions
until I Quit and restart.
Trying to solve the problem I have used the refresh method
on everything logical (I think)
DBEngine.Workspaces(0).Groups.Refresh
DBEngine.Workspaces(0).Users.Refresh
DBEngine.Workspaces(0).Users
("Updater").Groups.Refresh
DBEngine.Workspaces(0).Groups
("NewGroup").Users.Refresh
and many not so logical Collections
DBEngine.Idle
DBEngine.Workspaces.Refresh
DBEngine.Properties.Refresh
DBEngine.Workspaces(0).Databases.Refresh
DBEngine.Workspaces(0).Properties.Refresh
DBEngine.Workspaces(0).Databases(0).Containers
("Forms").Documents.Refresh
DBEngine.Workspaces(0).Databases(0).Containers.Refresh
DBEngine.Workspaces(0).Groups("Διαχειριστές").Users
(CurUse).Groups.Refresh
DBEngine.Workspaces(0).Users(CurUse).Groups
("Διαχειριστές").Users.Refresh
RefreshDatabaseWindow
DBEngine.Workspaces.Refresh

but still can't make it.
Can anybody please help me?
The full scenario follows.

User Updater is a member of the admins Group of the
Workgroup but has absolutely no permissions in the
Database objects of Updater.mdb except open/run and open
exclusive for the Database itself. His mission is to enter
the Database Updater.mdb and export Objects to another
Database Prog.mdb in which he cannot even enter.
There is a Group (actually 3 Groups) that have all the
necessary Permissions but they do not exist in the current
Workgroup and they should not exist after Updater finishes
the Job.
So when Updater enters Updater.mdb a function starts that
creates the necessary Groups, makes Updater a member,
exports the Objects, deletes the Groups again and quits
the Application.
I am geting the problem both when the Groups are Created
and when they are deleted.
Please HELP

 

[TC]

Greg, the way that you are going about this, is not approprate. Let's design
a better way.

As I understand it, UPDATER.MDB has been secured against a workgroup file,
let's call it UPDATER.MDW. Another database PROG.MDB has been secured
against a different workgroup file, PROG.MDW. A user defined in UPDATER.MDW,
needs to export some objects from UPDATER.MDB, to PROG.MDB. Is that correct?
If so, here's what I'd do.

(1) Create a user UPDATER in UPDATER.MDW. Do >not< make that user a member
of the Admins group, unless you want him to have administrative permissions
to UPDATER.MDB. He does not need to be a member of the Admins group, just to
do the exports in question.

(2) Log in to UPDATER.MDB as a member of the Admins group of UPDATER.MDW.
Give the UPDATER user enough permissions to export the objects in question.
I guess that would be Read Design and Read Data on each object in question
(but I don't have Access here to check).

(3) Now log in to PROG.MDB as a member of the Admins group of PROG.MDW.
Create a user also called UPDATER, in PROG.MDW. >>Make sure you use exactly
the same username, and PID, as the CREATOR user in CREATOR.MDW.<< Now, the
two CREATOR users (one in CREATOR.MDW, the other in PROG.MDW) are
indistinguishable to MS Access, from a security viewpoint. They look just
like the same person.

(4) Still logged in as a member of the Admins group of PROG.MDW, give the
new CREATOR user (in PROG.MDW) enough permissions to >import< all the
objects in question. I guess that would be Read Design, Delete Data, Write
Data, ...? on each object in question. Now log out of everything.

Now, if you log in to CREATOR.MDB as the CREATOR user, you should be able to
export the relevent objects from CREATOR.MDB to PROG.MDB.

Greg, I don't have Access here to check, so that is off the top of my head.
But I can definitely tell you this. You need to achieve your aim by defining
suitable user(s) in the two workgroup files. If that does not work quite the
way that you want, there are techniques whereby a "normal" user can
temporarily acquire the priviliges of some other (higher-privilged) user,
with the CreateWorkspace method. You would >not< do any of this by
dynamically creating or deleting groups, or adding/removing users from
groups.

HTH,
TC


I am creating a new Group with CreateGroup method and
leting an existing user join it. Everything works fine and
the changes are reflected in the User/Group accounts
window but the user does not gain the extra permissions
the Group has, until I exit and restart the Application
(meaning that using "DoCmd.TransferDatabase acExport..."
he gets the error that he cannot read Design of the
object, while being a member of the Group he should and
also if I exit my code and try to view the design of the
object I get the no permission message).
He also gains the extra permissions if I go to the
User/Group accounts window and manually remove and add
again the Group to the User.
Exactly the same happens when I use the delete method to
remove the Group. The User keeps his extra permissions
until I Quit and restart.
Trying to solve the problem I have used the refresh method
on everything logical (I think)
DBEngine.Workspaces(0).Groups.Refresh
DBEngine.Workspaces(0).Users.Refresh
DBEngine.Workspaces(0).Users
("Updater").Groups.Refresh
DBEngine.Workspaces(0).Groups
("NewGroup").Users.Refresh
and many not so logical Collections
DBEngine.Idle
DBEngine.Workspaces.Refresh
DBEngine.Properties.Refresh
DBEngine.Workspaces(0).Databases.Refresh
DBEngine.Workspaces(0).Properties.Refresh
DBEngine.Workspaces(0).Databases(0).Containers
("Forms").Documents.Refresh
DBEngine.Workspaces(0).Databases(0).Containers.Refresh
DBEngine.Workspaces(0).Groups("Διαχειρ&#9
53;στές").Users
(CurUse).Groups.Refresh
DBEngine.Workspaces(0).Users(CurUse).Groups
("Διαχειριστές")
..Users.Refresh
RefreshDatabaseWindow
DBEngine.Workspaces.Refresh

but still can't make it.
Can anybody please help me?
The full scenario follows.

User Updater is a member of the admins Group of the
Workgroup but has absolutely no permissions in the
Database objects of Updater.mdb except open/run and open
exclusive for the Database itself. His mission is to enter
the Database Updater.mdb and export Objects to another
Database Prog.mdb in which he cannot even enter.
There is a Group (actually 3 Groups) that have all the
necessary Permissions but they do not exist in the current
Workgroup and they should not exist after Updater finishes
the Job.
So when Updater enters Updater.mdb a function starts that
creates the necessary Groups, makes Updater a member,
exports the Objects, deletes the Groups again and quits
the Application.
I am geting the problem both when the Groups are Created
and when they are deleted.
Please HELP

 

[Greg]

Dear TC
Thanks for your responce. I have seen sugestions of yours
in plenty of Problems in the list and I found them very
interesting. They seem to come from a person who knows
what he is talking about (could TC stand for Technical
Contact?). Anyway about your sugestion to my problem, I
had already thought of it before, but I see it as a
security hole.
Let me explain you how I see Security and how things
actually are in my Databases.
There is a lets call it "secret.mdw" kept where changes to
my Databases occur. In that mdw there are all the Groups
with the necessary Permissions to change or even view
design of my Databases.
When I give a Database to a friend (Programming is my hoby
not my profession) it goes with a lets call it "given.mdw"
where the Groups included can only run the Application and
do whatever it was designed to do but there are absolutely
no Groups or Users with Permission to view the design of
objects. That is because I do not want to see my
Application on the Market unless I decide to put it there.
The reason I am trying to do this export is to provide
people changes I have made to the design of the Database.
Now you advised me to have a User in that "given.mdw", or
in more than one mdw's, which will be given to the
Enduser, who has the nesecery permissions to do the export

My comments
1) If that Superuser exists in the "given.mdw", plenty of
people could retrieve his User Name & Password and gain
access to everything.
2) If he was to be created by code on the spot and then
asked to run another or even the same Application, this
Action could be cancelled by the User and we would end up
with an mdw file containing that Superuser.=>1)
3) I would have nothing against a Superuser being created,
doing the job (Making changes to the Application) and then
being deleted in the same session but this would make it
hard to do the changes (since he is not the User running
the CurrentDB, he cannot export objects, which makes
keeping track of the changes easier, as it is easier to
remember that I have changed Form "A" since I gave it away
than to remember and repete in Code all the changes I did).

That was the reason I preffered to give an existing User
the appropriate permissions by creating and letting him
join the appropriate Groups and deleting the Groups
afterwards.
I bet there must be a way to make User Updater gain his
new Permissions right after he becomes a member of the
Groups granting him with them (since Access does it if I
manually remove him from the Groups and let him join them
again) but I can't find how.
If you know the way I would be obliged if you would share
it with me.
I am open in any other sugestions

If there is no way, I will try to bypass the Problem the
way you pointed out (opening another Workspace and a
second instance of the Database after having joined the
new Groups, and in there seting temporarily for my User
the Document(i).Permisions = Document(i).AllPermisions (or
the Permissions I need) until Object is exported). My
first try seems to be working.
I'll let you know what happened in a couple of days.
If you do know the way to get rid of all that by
refreshing (?) something(?) and leting the new Groups do
the job, please let me know.

Thanks in advance and
Merry Christmas
Greg

 

[TC]

Hi Greg

Thanks for the comments. No, TC does not stand for Technical Contact! (They
are my initials.)

I'll read your post & reply asap. However, it is 5:15pm here, I'm about to
be kicked-off this PC, & tomorrow is Xmas. So it might be up to 3 days. But
I >will< reply.

Cheers,
TC


Dear TC
Thanks for your responce. I have seen sugestions of yours
in plenty of Problems in the list and I found them very
interesting. They seem to come from a person who knows
what he is talking about (could TC stand for Technical
Contact?). Anyway about your sugestion to my problem, I
had already thought of it before, but I see it as a
security hole.
Let me explain you how I see Security and how things
actually are in my Databases.
There is a lets call it "secret.mdw" kept where changes to
my Databases occur. In that mdw there are all the Groups
with the necessary Permissions to change or even view
design of my Databases.
When I give a Database to a friend (Programming is my hoby
not my profession) it goes with a lets call it "given.mdw"
where the Groups included can only run the Application and
do whatever it was designed to do but there are absolutely
no Groups or Users with Permission to view the design of
objects. That is because I do not want to see my
Application on the Market unless I decide to put it there.
The reason I am trying to do this export is to provide
people changes I have made to the design of the Database.
Now you advised me to have a User in that "given.mdw", or
in more than one mdw's, which will be given to the
Enduser, who has the nesecery permissions to do the export

My comments
1) If that Superuser exists in the "given.mdw", plenty of
people could retrieve his User Name & Password and gain
access to everything.
2) If he was to be created by code on the spot and then
asked to run another or even the same Application, this
Action could be cancelled by the User and we would end up
with an mdw file containing that Superuser.=>1)
3) I would have nothing against a Superuser being created,
doing the job (Making changes to the Application) and then
being deleted in the same session but this would make it
hard to do the changes (since he is not the User running
the CurrentDB, he cannot export objects, which makes
keeping track of the changes easier, as it is easier to
remember that I have changed Form "A" since I gave it away
than to remember and repete in Code all the changes I did).

That was the reason I preffered to give an existing User
the appropriate permissions by creating and letting him
join the appropriate Groups and deleting the Groups
afterwards.
I bet there must be a way to make User Updater gain his
new Permissions right after he becomes a member of the
Groups granting him with them (since Access does it if I
manually remove him from the Groups and let him join them
again) but I can't find how.
If you know the way I would be obliged if you would share
it with me.
I am open in any other sugestions

If there is no way, I will try to bypass the Problem the
way you pointed out (opening another Workspace and a
second instance of the Database after having joined the
new Groups, and in there seting temporarily for my User
the Document(i).Permisions = Document(i).AllPermisions (or
the Permissions I need) until Object is exported). My
first try seems to be working.
I'll let you know what happened in a couple of days.
If you do know the way to get rid of all that by
refreshing (?) something(?) and leting the new Groups do
the job, please let me know.

Thanks in advance and
Merry Christmas
Greg

 

[TC]

Hi Greg

OK, your need is different to what I assumed. I assumed that you were only
copying >data< objects from one db to another. Now I realize that you want
to copy other objects like forms, reports etc. as well. This is so you can
update the design of the db that you provide to other people. Also, you want
to prevent those people from viewing the design of your objects, and/or,
marketing your db themselves. Correct?

If so, here are my thoughts & suggestions.

(1) Using transferdatabase to copy new/amended objects into the user's copy
of the database.

This usually means that your database has not been provided as a
"font-end/back-end" structure. With a FE/BE structure, all of the tables
(but none of the other objects) are in one database, called the BE. All the
other objects (queries, forms, reports, macros & modules) are in another
db - the FE. The FE has links to the actual tables in the BE.

One advantage of this structure, is that when you need to make changes, you
simply send a whole new FE to each user. They replace their old FE, with the
new FE. This ensures that all related changes are installed together. If any
of those changes cause unexpected problems, they simply replace the new FE,
with a saved copy of the old FE. This is waaaaaaaaay easier & safer than
using transferdatabase to copy new or amended copies of individual objects,
into the user's copy of the database.

I recommend that you change your database to use a FE/BE structure. Then,
all the problems related to using copyobject, become irrelevant. Certainly,
if you ever wanted to market your product, this would be an essential step.
Take that step now, to learn how it works!

(2) Protecting the design of your objects

By far the best way to protet the design of your queries, forms, reports,
macros & modules - that is, all of your SQL & VBA code - is to provide the
FE db as an MDE. Voila: problem solved. >Without< the need for user level
security. That is definitely, by far, the best way to protect the design of
those objects. And those are the objects that embody most of the "unique
intellectual property" within the database.

As for protecting the design of your >tables<, I personally feel that it is
not worth trying to do that. In a properly designed relational database, the
structure of the tables is easily reproduced, by re-analyzing the system
data according to normal relational prnciples. So you can "protect" that
structure as much as you like, but a competent developer can simply
reproduct it from scratch - probably without much effort. In effect, I
believe that there is not enough "unique intellectual property" within most
table designs, to make them worth protecting. So, forget protecting the
tables, & just supply them in an normal, unsecured, un-MDE'd back-end
database.

(3) Stopping people copying your database

This is a different issue completely. No matter >what< protections you place
on your database, you must give the user enough "things" to let them run the
database. So, if they can find what those "things" are (db files, registry
entries etc.), they just copy them to another PC, to add your system to that
PC.

There are maybe ways of stopping this, but that is really a whole 'nother
question in its own right!

So in summary, I recommend that you:
o split your db into a FE/BE structure;
o provide the FE as an MDE, and
o discard the current user level security approach.

I think that would solve your problems.

Just my 2c worth!

HTH,
TC





Dear TC
Thanks for your responce. I have seen sugestions of yours
in plenty of Problems in the list and I found them very
interesting. They seem to come from a person who knows
what he is talking about (could TC stand for Technical
Contact?). Anyway about your sugestion to my problem, I
had already thought of it before, but I see it as a
security hole.
Let me explain you how I see Security and how things
actually are in my Databases.
There is a lets call it "secret.mdw" kept where changes to
my Databases occur. In that mdw there are all the Groups
with the necessary Permissions to change or even view
design of my Databases.
When I give a Database to a friend (Programming is my hoby
not my profession) it goes with a lets call it "given.mdw"
where the Groups included can only run the Application and
do whatever it was designed to do but there are absolutely
no Groups or Users with Permission to view the design of
objects. That is because I do not want to see my
Application on the Market unless I decide to put it there.
The reason I am trying to do this export is to provide
people changes I have made to the design of the Database.
Now you advised me to have a User in that "given.mdw", or
in more than one mdw's, which will be given to the
Enduser, who has the nesecery permissions to do the export

My comments
1) If that Superuser exists in the "given.mdw", plenty of
people could retrieve his User Name & Password and gain
access to everything.
2) If he was to be created by code on the spot and then
asked to run another or even the same Application, this
Action could be cancelled by the User and we would end up
with an mdw file containing that Superuser.=>1)
3) I would have nothing against a Superuser being created,
doing the job (Making changes to the Application) and then
being deleted in the same session but this would make it
hard to do the changes (since he is not the User running
the CurrentDB, he cannot export objects, which makes
keeping track of the changes easier, as it is easier to
remember that I have changed Form "A" since I gave it away
than to remember and repete in Code all the changes I did).

That was the reason I preffered to give an existing User
the appropriate permissions by creating and letting him
join the appropriate Groups and deleting the Groups
afterwards.
I bet there must be a way to make User Updater gain his
new Permissions right after he becomes a member of the
Groups granting him with them (since Access does it if I
manually remove him from the Groups and let him join them
again) but I can't find how.
If you know the way I would be obliged if you would share
it with me.
I am open in any other sugestions

If there is no way, I will try to bypass the Problem the
way you pointed out (opening another Workspace and a
second instance of the Database after having joined the
new Groups, and in there seting temporarily for my User
the Document(i).Permisions = Document(i).AllPermisions (or
the Permissions I need) until Object is exported). My
first try seems to be working.
I'll let you know what happened in a couple of days.
If you do know the way to get rid of all that by
refreshing (?) something(?) and leting the new Groups do
the job, please let me know.

Thanks in advance and
Merry Christmas
Greg

 

[Greg]

Dear TC
Chrismass day is not for giving anybody programming
advices, so I have an even greater reason to thank you for
bothering.
Now:

OK, your need is different to what I assumed. I assumed that you were only
copying >data< objects from one db to another. Now I realize that you want
to copy other objects like forms, reports etc. as well. This is so you can
update the design of the db that you provide to other people. Also, you want
to prevent those people from viewing the design of your objects, and/or,
marketing your db themselves. Correct?

That is exactly the case.

(1) Using transferdatabase to copy new/amended objects into the user's copy
of the database.

This usually means that your database has not been provided as a
"font-end/back-end" structure. With a FE/BE structure, all of the tables
(but none of the other objects) are in one database, called the BE. All the
other objects (queries, forms, reports, macros & modules) are in another
db - the FE. The FE has links to the actual tables in the

BE.

Here you are wrong. My Databases have a FE/BE structure,
exactly because I know the advantages you are pointing out
and because BE is of an old MsAccess Version making the
Data accessible to whatever Version the User is using to
run his FE Databases.
So you might ask what the hell do I need TransferDatabase
and why am I not giving a new set of FE Databases.
Thats because I have found a nice way of as you said

(3) Stopping people copying your database

You are right, I have found no way to protect my
Application from being copied. I have found though a nice
way to stop people using it.
To achieve that, I need a single Table in the FE Database,
who's Data vary from User to User.
I don't think it would be safe to Give a common FE and use
another Database to change the Data to that particular
Table but I haven't given that possibility enough thought.
Till now, Data in that Table are not supposed to be
changed on the Users Computer at all (No User or Group has
Permission).

So I am stuck to using TransferDatabase
I supose neither you know the way I could really solve my
Problem (Create Groups, let a User join them and gain
their Permissions in the same Session).
I have found though a very nice way to Bypass the Problem
using the Problem itself. As I was saing, neither when I
Create Groups nor when I delete Groups, do the altered
Permissions exist in that session. So that's what I did.
1. Start the Database Updater.mdb with User Updater
2. Create the apropriate Groups and let Updater join them
3. Restart the Database Updater.mdb with User Updater (a
second instance)
4. Code running on the first instance deletes the Groups
5. Code running on the first instance Quits the first
instance.

So I end up with Updater.mdb running (the second instance)
where the Groups are not there any more, but User Updater
stil has their Permissions as if they were there (the
Problem became a solution) only for that particular
session.
You get an Error when Quiting the first instance, with
Access not being able to save the Users (exactly what I
would like it to do without Quiting) as it is locked by
another User (or something like that in the
Err.Description) but leting it just resume when the
Err.Number is that does the job.
I find that method quite good and not leting a hole in
security and think of using it. I write it to you as you
might face such a Problem some time.

If you do know a way to realy solve and not bypass the
Problem (Create Groups, let the current User join them and
giving some command let him gain their Permissions in the
same session) I would be really happy to hear it.
If not, have a happy New Year
Really happy to have discussed with you
Greg
P.S. I have seen no Question of yours in the list. If
there is one, guide me where to find it. I might be of use
as well.

 

[TC]

Hi Greg

I've just returned from an unexpected break, so I don't know if you'll get
to see this. But here goes anyway!

It seems that your problem is actually this. Your application already has a
FE/BE structure. But there is a security table in the FE. Thus, you can not
just provide the user(s) with a new FE. You need to copy the actual changed
bits only.

If that's the case, here's what I'd say. The security table is presumably
protected with user-level security. (If it wasn't, anyone could alter it, so
it would lose its value.) If so, just move it from the FE, to the BE! Then
you >can< provide them wth a new FE, whenever you want. I can't see that
moving the security table, would badly affect how your scheme works.

As for your original approach (creating groups at runtime), I feel that this
is doomed to failure. See the following thread in google groups:

<[email protected]>

Note: that is a google groups advanced search Message ID - not an email
address.

Cheers,
TC


Dear TC
Chrismass day is not for giving anybody programming
advices, so I have an even greater reason to thank you for
bothering.
Now:

OK, your need is different to what I assumed. I assumed that you were only
copying >data< objects from one db to another. Now I realize that you want
to copy other objects like forms, reports etc. as well. This is so you can
update the design of the db that you provide to other people. Also, you want
to prevent those people from viewing the design of your objects, and/or,
marketing your db themselves. Correct?

That is exactly the case.

(1) Using transferdatabase to copy new/amended objects into the user's copy
of the database.

This usually means that your database has not been provided as a
"font-end/back-end" structure. With a FE/BE structure, all of the tables
(but none of the other objects) are in one database, called the BE. All the
other objects (queries, forms, reports, macros & modules) are in another
db - the FE. The FE has links to the actual tables in the

BE.

Here you are wrong. My Databases have a FE/BE structure,
exactly because I know the advantages you are pointing out
and because BE is of an old MsAccess Version making the
Data accessible to whatever Version the User is using to
run his FE Databases.
So you might ask what the hell do I need TransferDatabase
and why am I not giving a new set of FE Databases.
Thats because I have found a nice way of as you said

(3) Stopping people copying your database

You are right, I have found no way to protect my
Application from being copied. I have found though a nice
way to stop people using it.
To achieve that, I need a single Table in the FE Database,
who's Data vary from User to User.
I don't think it would be safe to Give a common FE and use
another Database to change the Data to that particular
Table but I haven't given that possibility enough thought.
Till now, Data in that Table are not supposed to be
changed on the Users Computer at all (No User or Group has
Permission).

So I am stuck to using TransferDatabase
I supose neither you know the way I could really solve my
Problem (Create Groups, let a User join them and gain
their Permissions in the same Session).
I have found though a very nice way to Bypass the Problem
using the Problem itself. As I was saing, neither when I
Create Groups nor when I delete Groups, do the altered
Permissions exist in that session. So that's what I did.
1. Start the Database Updater.mdb with User Updater
2. Create the apropriate Groups and let Updater join them
3. Restart the Database Updater.mdb with User Updater (a
second instance)
4. Code running on the first instance deletes the Groups
5. Code running on the first instance Quits the first
instance.

So I end up with Updater.mdb running (the second instance)
where the Groups are not there any more, but User Updater
stil has their Permissions as if they were there (the
Problem became a solution) only for that particular
session.
You get an Error when Quiting the first instance, with
Access not being able to save the Users (exactly what I
would like it to do without Quiting) as it is locked by
another User (or something like that in the
Err.Description) but leting it just resume when the
Err.Number is that does the job.
I find that method quite good and not leting a hole in
security and think of using it. I write it to you as you
might face such a Problem some time.

If you do know a way to realy solve and not bypass the
Problem (Create Groups, let the current User join them and
giving some command let him gain their Permissions in the
same session) I would be really happy to hear it.
If not, have a happy New Year
Really happy to have discussed with you
Greg
P.S. I have seen no Question of yours in the list. If
there is one, guide me where to find it. I might be of use
as well.

 

[TC]

Of course, my suggestion would require adding security to the BE if it is
not already there. Or, you could secure the security table >without< having
to distribute a special workgroup file, by having the table owned by a user
who is not in any default workgroup file, and is >not< a member of the
default Users group. Thus, by default, no other users can access that table.
Then access it from the FE, via a Run With Owner Permissions (RWOP) query
owned by the same user who owns the table.

TC

 

[TC]

Replied to other thread.

TC

Hi Greg

Thanks for the comments. No, TC does not stand for Technical Contact! (They
are my initials.)

I'll read your post & reply asap. However, it is 5:15pm here, I'm about to
be kicked-off this PC, & tomorrow is Xmas. So it might be up to 3 days. But
I >will< reply.

Cheers,
TC


Dear TC
Thanks for your responce. I have seen sugestions of yours
in plenty of Problems in the list and I found them very
interesting. They seem to come from a person who knows
what he is talking about (could TC stand for Technical
Contact?). Anyway about your sugestion to my problem, I
had already thought of it before, but I see it as a
security hole.
Let me explain you how I see Security and how things
actually are in my Databases.
There is a lets call it "secret.mdw" kept where changes to
my Databases occur. In that mdw there are all the Groups
with the necessary Permissions to change or even view
design of my Databases.
When I give a Database to a friend (Programming is my hoby
not my profession) it goes with a lets call it "given.mdw"
where the Groups included can only run the Application and
do whatever it was designed to do but there are absolutely
no Groups or Users with Permission to view the design of
objects. That is because I do not want to see my
Application on the Market unless I decide to put it there.
The reason I am trying to do this export is to provide
people changes I have made to the design of the Database.
Now you advised me to have a User in that "given.mdw", or
in more than one mdw's, which will be given to the
Enduser, who has the nesecery permissions to do the export

My comments
1) If that Superuser exists in the "given.mdw", plenty of
people could retrieve his User Name & Password and gain
access to everything.
2) If he was to be created by code on the spot and then
asked to run another or even the same Application, this
Action could be cancelled by the User and we would end up
with an mdw file containing that Superuser.=>1)
3) I would have nothing against a Superuser being created,
doing the job (Making changes to the Application) and then
being deleted in the same session but this would make it
hard to do the changes (since he is not the User running
the CurrentDB, he cannot export objects, which makes
keeping track of the changes easier, as it is easier to
remember that I have changed Form "A" since I gave it away
than to remember and repete in Code all the changes I did).

That was the reason I preffered to give an existing User
the appropriate permissions by creating and letting him
join the appropriate Groups and deleting the Groups
afterwards.
I bet there must be a way to make User Updater gain his
new Permissions right after he becomes a member of the
Groups granting him with them (since Access does it if I
manually remove him from the Groups and let him join them
again) but I can't find how.
If you know the way I would be obliged if you would share
it with me.
I am open in any other sugestions

If there is no way, I will try to bypass the Problem the
way you pointed out (opening another Workspace and a
second instance of the Database after having joined the
new Groups, and in there seting temporarily for my User
the Document(i).Permisions = Document(i).AllPermisions (or
the Permissions I need) until Object is exported). My
first try seems to be working.
I'll let you know what happened in a couple of days.
If you do know the way to get rid of all that by
refreshing (?) something(?) and leting the new Groups do
the job, please let me know.

Thanks in advance and
Merry Christmas
Greg