How User ID work in MS Acces 2000 ?

[PNGBill]

Hi Forum,

We have an MS Access 2000 database and we login as users with an ID.

This was setup by experts that are now no longer available.

I can do a fair bit with the database but we have some activities that are user and user group related ie an administrator can do "this" only.
When we record messages with a form the form knows who the user is so the message table is updated with details including the user.

I know there is more to my question then a quick response can cover but for now if I could be directed into an area of research and then I can ask specific questions as i learn.

We have a TBLTeamMembers that holds our Initials (key) full name and Team Status.

This sql statement "SELECT T.TeamID, T.TeamFirstName & ' ' & T.TeamLastName As Operator FROM TBLTeamMembers AS T;" is row source data in a Combo Box of a form to create a new message.

The sql looks simple in that it selects the id, firstname & lastname from the above table but... why does it not select all of them?? where would the form hold who actually logged into the database??

Enough for now and appreciate some advice.

 

[The_Doc_Man]

This is a difficult question to answer because it is missing details we would need.

The question of why a rowsource doesn't select everything from a table is probably because it doesn't need everything in that row. I'm betting that the bound column in that combo box is 1 but the ID number isn't displayed. If so, then what is happening is that the ID number is being stored in VBA behind the form and any other account properties or roles are being looked up later based on the ID. I know that's sort of how I do my security.

I suggest you look at the code and see what is going on. The VBA can be examined for each form. That code will be mostly event-driven, so read up on events and recognize that Access will call your event subroutines when a specific condition (event) is found. More than one event can be activated in a specific sequence. VBA programming in Access is therefore about deciding not only what you know but when you know it. You use the event code to take advantage of things you have just learned when a change is made on the form.

When you break up form activities based on events, you get an automatic "divide and conquer" effect that can often be useful in organizing what you do. Think of event code as opportunities for your form to call your code when it thinks it is appropriate based on the named event. That is probably where the form "decides" who has just logged in and what rights they have.

In summary, my suggestion for your starting point is the VBA code underneath the form.

 

[PNGBill]

Thanks for the detail.

Here is an excerpt from the forms On Current event procedure.

'Get current operator
Me.cboOperatorID = UCase(CurrentUser)

So I guess for the pc that I am using that I logged into access as user "name" then it holds my ID in cboOperatorID ??

I can call this up from any form in the database?? and it would hold the respectives user details.

I am also assuming that any one pc can only log in once at a time to this database - of course why would we need to do otherwise.

We have three users on 3 pc's so each pc knows it's respective operator or is it the database on each pc?

Forgive me if I am going in wild circles here.

Could I have the operator on each form (main ones) so they see their name as they work - just in case they forget