Username and Usergroup

[jokobe]

Hi ng,

when starting a secure database(ACC2000) the user have to
give his username and his password. Within the database I
do need the username and the usergroup for some
queries/and forms. Is there a chance to catch the username
when starting the database?

thanks in advance

jokobe

 

['69 Camaro]

Hi.

After the user has successfully logged into the secure database, use the
following function to determine the user's UserID:

CurrentUser( )

Since users are often members of multiple groups, it would probably be
better to find out whether the current user was a member of a specific group
that has the permissions to run a certain query or open a certain form. You
can use code such as the following to determine whether a user is a member
of a specific group:

'=======================================
' Function: isMemberOfGrp( )
' Returns True if the user is in the group.
' Usage: isMemberOfGrp(CurrentUser(), "Admins")
'=======================================

Public Function isMemberOfGrp(sUserName As String, sGrpName As String)

On Error Resume Next

Dim junk As String

junk = DBEngine(0).Users(sUserName).Groups(sGrpName).Name

'-------------------------------------------------------------------
' Determine whether checking this Property
' caused an error or not.
'-------------------------------------------------------------------

If (Err.Number = 0) Then
isMemberOfGrp = True
Else
isMemberOfGrp = False
End If

Err.Clear

End Function

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[TK]

I'm curious - what is the point of this function? If the user is not in the
group that has the permissions to run the query in question, or open the
form, etc. - they already won't be able to do so and Access will gladly let
them know.
So why are you trapping that when opening the db?
Just wondering.
TK

 

['69 Camaro]

Hi, TK.

I'm curious - what is the point of this function? If the user is not in the
group that has the permissions to run the query in question, or open the
form, etc. - they already won't be able to do so

You have a valid point about the security permissions for running queries or
opening forms. However, Jokobe didn't ask how to control these operations.
While you may disagree with me, after reading the request I interpreted
Jokobe to be requesting information for how to capture the user name and
group name to _use_ for some queries and forms:

Access developers who need to customize database applications require a lot
more flexibility than just the ability to limit who runs which queries or
who opens which forms. These two functions I posted below allow much more
granularity of the security permissions assigned and help prevent
duplication of development and maintenance efforts.

For example, a form that has multiple inputs from various users of two
groups, "Data_Input" and "Supervisors," should have sufficient permissions
to enable both groups to open the form. However, the form's "Approved"
field should be locked for the "Data_Input" users so that they can't make
changes to it. If a developer didn't have the ability to determine whether
the current user was not a member of the "Supervisors" group in order to
lock that field when the form opens, then there would have to be two
different forms, one for members of the Data_Input" group (which lacks an
"Approved" field) and another one for members of the "Supervisors" group
(which displays all fields). Having two separate forms doubles the
developer's efforts required to make changes to the form, so this is not
desirable.

Queries can also be customized by filtering records from tables that
multiple groups are permitted to view, including when certain fields are not
necessary for members of some of the groups. Instead of creating multiple
queries that are nearly identical, one for each group, a single query can be
created and filtered with the WHERE clause, HAVING clause, and/or IIF( )
function.

So why are you trapping that when opening the db?

I didn't mention it, but with the functions I posted below, there's no need
to trap the user name or user group upon opening the database. These
functions will return the correct values at any time while the database
application is running, so there's no need to capture and save them for
later use.

Does this explanation satisfy your curiosity?

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[TK]

69 Camaro,
No - I wasn't disagreeing with you at all and I fully agree with the
methodology you have proposed.
My question was actually for jokobe - as to why he/she feels they need to
trap this in the first place. I can see if they are setting permissions on
the fly through code - and maybe that is what is happening, but the original
post just seemed as though they wanted to know who was in the allowed
group(s) and who wasn't.
TK

 

['69 Camaro]

Hi, TK.

You could very well be correct. Perhaps Jokobe could post back and clarify
the intent of the capture of the user name and group at login.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)