Corrupt MDW - About Had It :mad:

Pauldohert said:
This is probably really dumb - but how do users get added etc when the mdw has mulitple copies one for each PC?

Paul

Same thing I was wondering- just didn't want to open that can of worms :) ...

Ken
 
I keep the master files [mdb and mdw] on my PC. I only create a login ID for each "group" of users. Each group has their own set of permissions. If I need to know who the user is then I just use their network ID. That way I do not have to worry about 100+ user IDs. Too many people make that mistake and create login IDs with Access security for each user [way too much maintenance] . Technically, only the newest user groups need the latest mdw file but I always update everybody files [see above post] when I publish an update.
 
Does not sound very secure, having generic logins. Sounds more like business rules via the .mdw...

But if it works for you :)

Ken
 
Oh they are secure. Each workgroup is defined by the user's job tasks or level of responsibility. The shortcut only opens the login prompt with their user ID, they still have to supply the correct password. I know if a user tries to open the db without using their special shortcut and all users logins are tracked. All records are tagged with the users ID so that we know who modified the record and when. There is a lot more to it than that but that it the short version.
 
ghudson said:
...The shortcut only opens the login prompt with their user ID, they still have to supply the correct password.

Is this the Access Login Prompt?

Ken
 
Yes. All users are given a special shortcut that has a Target field like this...

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /runtime /wrkgrp "X:\WorkgroupFile.mdw" "X:\DatabaseFile.mdb" /user UserName

We do not join a PC to a specific workgroup [well, the default join is to the System.mdw file]. We only use special shortcuts to allow the user to open a secured db.
 
Where does it get 'UserName'?

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /runtime /wrkgrp "X:\WorkgroupFile.mdw" "X:\DatabaseFile.mdb" /user UserName

Ken
 
That is hardcoded into the target field. That was just an example. I create a special shortcut for each workgroup and I send it to the users. I create self extracting files with WinZip Self-Extractor 2.2 to install the shortcut to the users Start button in a custom directory off of their Programs directory.
 
I have a few dbs that are secured to protect the design [and my code] but I do not care who logs into the db and there is only one workgroup [user name]. For those I give them a special shortcut that provides everything so that they open the db without logging in because the shortcut contains the workgroup name and the password.

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /runtime /wrkgrp "X:\WorkgroupFile.mdw" "X:\DatabaseFile.mdb" /user UserName /pwd SpecialPassword
 
Let me get this straight;

1. You have a .mdb with data tables on a network share drive
2. Each user has a copy of the fe/.mdb on their local machine
3. Each user has a copy of the .mdw on their local machine
4. You have no actual user names defined in the .mdw (other than maybe an admin)
5. When a user opens the db they actually make it past the the .mdw by signing in as say "UserGroupA" with a password of say "GroupAPassword"
6. All of this is hardcoded into a short cut that you distribute to each machine where some kind of script places it into the start menu.

-Break- (whew)

7. Now, during the course of the database being used, you're putting the network userID in some fld(s) in a some table(s) in the be/.mdb on the network share drive to see who is doing whatever

???
Ken
 
Yes to it all except I do have workgroup names with specific user permissions within the mdw. Admin is removed except the security piece to open the db, that way I get notified if somebody tries to open the db without the shortcut. Say for example I have one secured db that has four different workgoups within one mdw. Here is a simplistic example of the 4 different user workgroups and their permissions.

PayrollClerk [able to view and add but not delete data]
PayrollSupervisor [able to view and add and delete data]
PayrollViewer [able to view data]
Programmer [me, I have full access]

No need to create a workgroup name with special permission for each Tom, Dick, and Harry. Their job code or level of responsibility will determine which user workgroup they are in and I customize that with the shortcut they have installed.

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /runtime /wrkgrp "X:\WorkgroupFile.mdw" "X:\DatabaseFile.mdb" /user PayrollClerk

Each record has a modified "by" and modified "when" field in the table. The supervisor and manager groups get to see that data on the form, the clerks and viewers do not see those fields.

The db will display a message if the user tries to open the db without the correct shortcut and then close down. The message will tell them what they have done wrong. It will list their network ID name, thier computer name and all of that is included in my email so I have proof if an unauthorized person tried to open it. It is a good scare for the curious.
 
How do you give people the correct shortcuts?

If someone has the wrong shortcut - ie programmer with programmer password are they then in?

Paul - sorry if I am being dumb!
 
No, I never include the user login name with the password if the db has multiple workgroup names. Nobody has my programmer password [outside of my group] and I do not have my passwords hardcoded into the shortcut.

As I stated above,
I create a special shortcut for each workgroup and I send it to the users. I create self extracting files with WinZip Self-Extractor 2.2 to install the shortcut to the users Start button in a custom directory off of their Programs directory.
I only include the user name in their shortcut and they have to key the password for their workgroup to log in.

I email the self extracting file so that they get the correct shortcut. If a new user inherits a PC and they need a different login then I just tell them how to edit the target field of the shortcut or I do it if I am at their PC.
 
Check this link out if you want to extract the users full name [first and last] from thier network ID. I use it when needed. It only works with Windows XP/NT/2000.
Capture UserName with UserID
 
...or

If someone has enough wits about 'em to look at the shortcut seems you'd be hosed...

I think I'd just do the role stuff inside the db with a 'network user name -> role' type table. When someone new comes around, open a form type in the network user name and assign 'em a role.

But it sounds like you have it working to suite your needs :)

Ken
 
I think I figured out the problem.

Several people were pointing to the mdw file that was getting corruped via the workgroupadmin.exe file. They were using a shortcut for my database but opening other databases directly on their PCs. So there was multiple entries for the same user in the mdw file. I changed the wrkgadm.exe file on those PCs to point to a different mdw file.

The audit trail is an awesome part of the program. The unique logon IDs makes this possible. We could never logon with a generic user. We are FDA regulated and that goes against 12CFRPart11 - the rules that go to computer systems in a FDA GMP environment.
 
If someone has enough wits about 'em to look at the shortcut seems you'd be hosed...
How so? That only tells them the user name. They still need the password to log in. Those that do log in only know the password for their workgroup name. But, if somebody gets cute and learns of another groups ID and password and logs in with an ID and password that for a group that they do not belong to then the db user log will show who the user is, which PC they used and which group they logged in as. [bad sentence structure]
 
workgroupadmin.exe
You should never join a PC to a workgroup. Using custom shortcuts like I mentioned above enables the user to login to the db with the right workgroup.mdw file. Joining a PC to a workgroup would force the user to log into each db, even to create a brand new mdb file.
 

Users who are viewing this thread

Back
Top Bottom