Access Securities - Changing Users w/o Closing the application 2

[phcar]

Is there a procedure for changing the current user without closing and reopening the database? Can the user log-on dialog be initiated w/in the current database?

 

[JeremyNYC]

No can do.

What are you trying to do?

Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access Databases Since 1995

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[phcar]

We're storing an audit trail that captures the user name and the associated field whenever data is changed. Since multiple users have access to a single computer, we need to be able to quickly switch the user name without the added hassle of closing and reopening the database.

 

[JeremyNYC]

Wow. I have a hard time beleiving I'm about to do this but...this might be a time when it's better not to use Access's user-level security.

Actually, what I would say is that you should still use security to log into the database but then provide an interfact for users to say "I'm using the database now." Then, instead of picking up the user from Access, you can get it from the form you created for this purpose (which would stay open but be made invisible while the database is being used).

Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access Databases Since 1995

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[MichaelRed]

also implies some re-writing, as the corrent susyem surely uses 'CurrentUser' for the log function. That should probably be replaced.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[phcar]

That's useful for getting around the close and reopen issue, but negates any securities I've built around restricting movement w/in the database, e.g. the person who initially logs in might have different access securities than the one who changes the user name after the database is already open. How do I get around that? Why does 'CurrentUser' gotta go?

 

[JeremyNYC]

You'll have to get the information from somewhere else, as I suggested, because currentUser comes from access/JET and is connected to the person who logged in.

You're right that this will defeat user-level security.

It probably makes more sense to make your front end light enough that it's not a chore to log off and log on again. That way you can still use user-level security.

Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access Databases Since 1995

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[RickSpr]

If you're that concerned with restricting access to database objects, I have to assume the old user is expected to do some kind of logoff function that you use to display a logon dialog for the next user. The new user then has to enter his name and password.

At that point, you could use the Shell() function to start a new instance of the FE, passing /wrkgrp, /user and /pwd on the command line, followed by terminating the old instance.

It wouldn't save much time, but if your users are complaining that finding and double clicking the database is inconvenient, it would at least solve that problem. (Of course, you could also just put a shortcut to the database on the Start Menu.) Rick Sprague
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[SgtJarrow]

To throw in my couple of cents....it is normally common practive that most users have approximately the same level of access, with a couple of "super" users, and admin or two, and then the developer....

If the majority of your users have the same access, create one login for them all to use. Then use the cstom form to hold the name for the audit trail as suggested by JeremyNYC. Finally, provide the "super" users a way to close and reopen the dataabse with "super" rights.....

This would still restrict the common user, give the "super" users access to what they need, and allow a fairly simple setup to get what you are looking for... Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Albert Einstein)

Robert L. Johnson III, MCP, Network+, A+
Access Developer/Programmer
robert.l.johnson.iii@citigroup.com

 

[phcar]

Thanks for the input. This is a rehabilitation database with multiple users from a variety of clinical areas (e.g. physical therapists, occupational therapists, speech therapists, physiatrists, psychiatrists). Because of the sensitive nature of the medical records and new Federal guidelines (HIPAA), we're forced to be fairly restrictive in terms of who accesses the DBase, in addition to limiting access based on service type. The levels of access are, in fact, quite complicated, rendering the user/super user approach inadequate. Complicating this are the requirements of our network environment (IS protocols) which dictates that the shortcut be located on our intranet page (a three step procedure). I'll probably experiment with the shell function and post the solution once I've worked it out.

 

[Grumbledook]

phcar, there is a way of doing it using mdw file. I gleaned this method for access 2002 from another forum:
Place the following in the onclick event code of the button:
-----------------------------------------------------------------------

Dim strPath as String

strPath = Chr(34) & "(Enter full path to MSACCESS.EXE)" & Chr(34) & " " & Chr(34) & _
CurrentProject.FullName & " " & Chr(34) & _
"/user " & CurrentUser & " /wrkgrp " & Chr(34) & "(Enter the Full Path to your).mdw" & Chr(34)

Shell strPath, vbMaximizedFocus
Application.Quit

-----------------------------------------------------------------------
It seems to work for me. It defaults to the password screen of the current user, and you just enter the new user and password as normal. The code itself may require manipulation depending on which version you have and where the MSACCESS.EXE and the MDW files are stored.

This is how it looks in my Application:
----------------------------------------------------------------------------

Dim strPath As String

strPath = Chr(34) & "C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" & Chr(34) & " " & Chr(34) & _
CurrentProject.FullName & " " & Chr(34) & _
"/user " & CurrentUser & " /wrkgrp " & Chr(34) & "C:\Documents and Settings\Owner\My Documents\Secured1.mdw" & Chr(34)

Shell strPath, vbMaximizedFocus
Application.Quit

------------------------------------------------------------------------

Hope this helps

Dave

 

[phcar]

Thanks Grumbledook - works like a charm. You've taken a 4 step procedure down to 1.