Get the Current Logged In User in MS Access 2003

[Guest]

MS Access 2003

I would like to get the Current Logged In User (the login Id) to stamp a
record with the creation user.

The CurrentUser() function returns "Admin" instead of the Current Logged In
user that created the record.

Any ideas ?
Thank you

 

[Arvin Meyer [MVP]]

Without implementing user-level security, all users are "admin" You can get
the computer user's login name:

http://www.mvps.org/access/api/api0008.htm

 

[Joan Wild]

CurrentUser() returns the Access username of the person currently logged in. This is only relevant if you implemented user-level security in Access. Since you are getting 'Admin', that suggests the mdb isn't secured.

If you want the windows username, you'll find a function at
www.mvps.org/access/api/api0008.htm
to do this.

 

[(PeteCresswell)]

Per John sd:

I would like to get the Current Logged In User (the login Id) to stamp a
record with the creation user.

The CurrentUser() function returns "Admin" instead of the Current Logged In
user that created the record.

I stopped bothering with the MS Access login and now always use
the LAN ID.

The code below is wretched excess - but that's what I started out
with and that's what I'm using now....

Hopefully, somebody else will chime in with a one-liner to do the
same thing:
------------------------------------------------------------
Private Declare Function GetUserName Lib "advapi32.dll" Alias
"GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long

Public Function CurrentUserGet() As String
1000 debugStackPush mModuleName & ": CurrentUserGet"
1001 On Error GoTo CurrentUserGet_err

' PURPOSE: To return the name of the person currently logged
' on.
' RETURNS: (you guessed it!)
'
' NOTES: 1) No sense going through any extra processing,
' so we work through the static and only invoke
' userIdWindowsGet() the first time.
' 2) We have a temporary workaround here.
' If somebody has Admin authority over their PC,
' the NetWare logon process logs them
' on to Windows as "Administrator" - creating a
' problem for us.

1002 Dim winUser As String

Static myCurrentUser As String

1010 If Len(myCurrentUser) = 0 Then
1011 winUser = userIdWindowsGet()
1019 myCurrentUser = winUser
1199 End If

1999 CurrentUserGet = myCurrentUser

CurrentUserGet_xit:
DebugStackPop
On Error Resume Next
Exit Function

CurrentUserGet_err:
BugAlert True, ""
Resume CurrentUserGet_xit
End Function

Private Function userIdWindowsGet() As String
debugStackPush mModuleName & ": userIdWindowsGet"
On Error GoTo userIdWindowsGet_err

' PURPOSE: To retrieve the Windows UserID of the person currently
' logged on to this PC
' RETURNS: UseID or empty string

Dim myBuffer As String * 255
Dim myUserName As String

GetUserName myBuffer, Len(myBuffer)

'Get the user name
myUserName = Left(Trim(myBuffer), InStr(myBuffer, Chr(0)) - 1)
'Trim excess characters

If Len(myUserName) > 0 Then
userIdWindowsGet = myUserName
Else
BugAlert True, "Unable to get Windows UserID"
End If

userIdWindowsGet_xit:
DebugStackPop
On Error Resume Next
Exit Function

userIdWindowsGet_err:
BugAlert True, ""
Resume userIdWindowsGet_xit
End Function

 

[Douglas J. Steele]

No one-liner, but I thought I'd point out that the average user is going to
have to remove the line that starts debugStackPush ... since that's a custom
function you didn't supply!

 

[(PeteCresswell)]

Per Douglas J. Steele:

I'd point out that the average user is going to
have to remove the line that starts debugStackPush ... since that's a custom
function you didn't supply!

As with DebugStackPop and BugAlert.

 

[louisjohnphillips]

Per Douglas J. Steele:


As with DebugStackPop and BugAlert.

This solution would only work in a Windows environment because it uses
a call to a Windows DLL.

However, it retrieves the logged in user name quite simply. In the
application code, just call sUserName = vbGetUserName().

Private Declare Function GetUserName Lib "advapi32.dll" Alias
"GetUserNameA" (ByVal szUserName As String, cbMaxLen As Long) As Long

Public Function vbGetUserName() As String

Dim cbMaxLen As Long
Dim sUserName As String * 16
Dim cbRetCode As Long

cbMaxLen = 16

cbRetCode = GetUserName(sUserName, cbMaxLen)
cbMaxLen = cbMaxLen - 1

vbGetUserName = Left(sUserName, cbMaxLen)

End Function

..

 

[(PeteCresswell)]

Per (e-mail address removed):

However, it retrieves the logged in user name quite simply. In the
application code, just call sUserName = vbGetUserName().

Private Declare Function GetUserName Lib "advapi32.dll" Alias
"GetUserNameA" (ByVal szUserName As String, cbMaxLen As Long) As Long

Somewhere, somebody posted a one-liner.

Something about "Environment".

 

[Douglas J. Steele]

Per (e-mail address removed):

Somewhere, somebody posted a one-liner.

Something about "Environment".

I always cringe when someone suggests using the Environment variable to get
the user information, given how easy it is to reset an Environment variable.

To those who don't care, the one liner would be Environ$("USERNAME")

However, try the following.

1. Create a database that has an AutoExec macro that invokes a message box
that has its Message set to =Environ("USERNAME") (complete with = sign)
2. Open the database normally. The message box should display your userid.
3. Open a command prompt (a "DOS box") and set SET USERNAME=xxx
4. While in the same command prompt box, start your database from the
command line (to do this, you can either use "Start <full path to
database>", or "<full path to msaccess.exe> <full path to database>".
Remember to enclose the paths in quotes if they include spaces) The message
box should now display xxx

Now, when you close the command prompt, the USERNAME variable will be
correct again (and if you were to open the database normally while the
command prompt was still open, your message box would still display your
correct user name). However, what's to stop a user from starting your
application using the "stealth" approach?


At one time, our login script actually removed the USERNAME variable from
the environment, just so people wouldn't rely on it, but we've since
accepted that some vendors aren't that savvy, and we now leave it in.

 

[Guest]

Awesome and many thanks, all for the input !

I always cringe when someone suggests using the Environment variable to get
the user information, given how easy it is to reset an Environment variable.

To those who don't care, the one liner would be Environ$("USERNAME")

However, try the following.

1. Create a database that has an AutoExec macro that invokes a message box
that has its Message set to =Environ("USERNAME") (complete with = sign)
2. Open the database normally. The message box should display your userid.
3. Open a command prompt (a "DOS box") and set SET USERNAME=xxx
4. While in the same command prompt box, start your database from the
command line (to do this, you can either use "Start <full path to
database>", or "<full path to msaccess.exe> <full path to database>".
Remember to enclose the paths in quotes if they include spaces) The message
box should now display xxx

Now, when you close the command prompt, the USERNAME variable will be
correct again (and if you were to open the database normally while the
command prompt was still open, your message box would still display your
correct user name). However, what's to stop a user from starting your
application using the "stealth" approach?


At one time, our login script actually removed the USERNAME variable from
the environment, just so people wouldn't rely on it, but we've since
accepted that some vendors aren't that savvy, and we now leave it in.