Change Workgroup Permissions using VBA 1

[RichD]

HI,

I am trying to change permissions so that users can export tables to a backup file, and then once the backup is created, change their permissions back so that they cannot open the backup. (so that the backup cannot be changed.

This is my code :

'********************************
Dim W As Workspace, U As User

Set db = CurrentDb()
Set W = DBEngine.CreateWorkspace("NewWS", "AdminGuy", "AGPassword&quot
Set U = W.Users("user01&quot

U.Groups.Append U.CreateGroup("Admins&quot

W.Users.Refresh
W.Groups.Refresh
W.Databases.Refresh

'export code here
'********************************

The problem I have is that the code updates the workgroup file to add Admins group to User01, but it does not take effect until you log out and repoen the mdb. I have tried refreshing eberything (as you can see).

Any help greatly appreciated.

Rich

Lead Developer

http://www.blsoftware.co.uk

 

[oharab]

Why don't you do all the exporting in the Admin guy workspace?
You may need to change the export code, but if youpost the code here, I will look at it.

hth


B

----------------------------------------------
Ben O'Hara

http://www.RobotParade.co.uk

"Where are all the stupid people from...
...And how'd they get so dumb?"
NoFX-The Decline
----------------------------------------------

 

[RichD]

Thanks Ben,

The application will be deployed as an MDE and the AdminGuy workspace will not be available to users.

The export code works OK.

When the procedure to add the Admin group to User01 is run, I checked Secuity - User Accounts and could see that Admin had been added to User01. I then tried to open a form in design view, which Admin users can do. But User01 still did not have permission to do so. That's how I knew the permission did not take effect until you quit and re-enter. (because when I did that User01 had full permissions).

What I need to do is try to refresh the security file / table so that User01 has full permissiions without having to quit and re-enter.

Thanks for your help.

RD

Lead Developer

http://www.blsoftware.co.uk

 

[oharab]

You should be able to do something like this:

Dim W As DAO.Workspace
Dim ThisDB As DAO.Database
Dim ExportDB As DAO.Database
Dim ThisTD As DAO.TableDef
Dim NewTD As DAO.TableDef
Dim Thisfld As DAO.Field
Dim Newfld As DAO.Field

Set ThisDB = CurrentDb
Set W = DBEngine.CreateWorkspace("NewWS", "AdminGuy", "AGPassword&quot
Set ExportDB = W.CreateDatabase("C:\ExportDB.mdb", dbLangGeneral)
For Each ThisTD In ThisDB.TableDefs
Set NewTD = ExportDB.CreateTableDef(ThisTD.Name)
For Each Thisfld In ThisTD.Fields
Set Newfld = NewTD.CreateField(Thisfld.Name, Thisfld.Type, Thisfld.Size)
NewTD.Fields.Append Newfld
Set Newfld = Nothing
Next Thisfld
ExportDB.TableDefs.Append ThisTD
Next ThisTD
...Export records to tables in similar way...


I've not tested it, but it should create the db & the tables as if the AdminGuy user had created them.


hth

Ben

----------------------------------------------
Ben O'Hara

http://www.RobotParade.co.uk

"Where are all the stupid people from...
...And how'd they get so dumb?"
NoFX-The Decline
----------------------------------------------

 

[MichaelRed]

Something is (I think) slightly awry. You say " ... AdminGuy workspace will not be available to users ... " - but it (obviously) must exist per your "hard coded" process before any activity can occur, so the issue boils down to the the tag end of the phrase " ... not be available to users ... . So that is a choice - not a mandate. Since the 'choice' is so arbitrary, why donn't you change it?

Further, you speak of exporting "tables", but this is quite a bit different than exporting the CHAANGES (to the table data), and CAN (when executed repeatedly) create multiple instances on the data (or, if not properly handled) failure in the export routine.

Mr. O'Hara has offered to review your code in some additional depth, after offering suggestions which -at least at a glance- appear to be the mnore normal approaches to the issue, yet yocontinue to insist on a soloution which is based on incomplete documentation of the process your are attempting and strays from the traditional (and thus more easily envisioned) path.





MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[RichD]

Many thanks Ben and Michael for taking the time to help me with the problem.

The reason I tried to temporarily change the permissions of user01 was so that I could use the extensive export code already written and tested.

Another advantage of temporarily changing the permission of a user (while in the application), would be that the user would be able to manipulate objects outside the scope of DAO.

Unfortunately this does not seem possible so I shall return to the traditional path and use Ben's code.

Thanks again,
Rich

Lead Developer

http://www.blsoftware.co.uk