Textbox to display login id in form, few other things :O

[Dclassen89]

I have a login system that calls to a table for usernames and passwords then loads a form if login is successful. I want to display the current users username on the 2nd form that is loaded. This would allow me to draw from this text field to accomplish other things with my DB. Secondly I would like to add buttons to my form which draw from this textbox to show only records matching that login id ( I have the login id in the table for the main form after login),and records where the login id is blank. Hope that makes sense.

[ItsMe]

You could store the login ID in a public variable when you first take a trip to the data to verify the user's input. You could also use open args when you open the other form with DoCmd

[Dclassen89]

You could store the login ID in a public variable when you first take a trip to the data to verify the user's input. You could also use open args when you open the other form with DoCmd

Whichever would be easier to implement. So I could just add code to my current login button that would plug the data into the 2nd form?

Here is my current login button code. If it could just be added to this that would be great.

Private Sub Login_Click()
If Me.txtPwd = Me.cboLogin.Column(2) Then
curUser = Me.cboLogin.Column(0)
DoCmd.Close acForm, "LogonForm"
DoCmd.OpenForm "AgentView", , , "AgentID = '" & Me.cboLogin.Column(1) & "' OR AgentID Is Null"



Else
If ct < 4 Then
MsgBox "Password not recognized. Try again!", vbOKOnly, "My Project"
ct = ct + 1
Else
DoCmd.Quit
End If
End If
End Sub

[ItsMe]

What is curUser? is this the user name that you want to display?

it seems as though you have the info you need in the combo. I just don't know what column.

Maybe
DoCmd.OpenForm "AgentView", , , "AgentID = '" & Me.cboLogin.Column(1) & "' OR AgentID Is Null",,, curUser

and then in the form load event
Me.txtBoxToDisplayName = Me.openargs

[Dclassen89]

Me.cboLogin.Column(1) The value i want is here this column stores the username.

[ItsMe]

You can get the value straight from the control
DoCmd.OpenForm "AgentView", , , "AgentID = '" & Me.cboLogin.Column(1) & "' OR AgentID Is Null",,,Me.cboLogin.Column(1)

Now it will be in form AgentView's Open Args

[Dclassen89]

You can get the value straight from the control
DoCmd.OpenForm "AgentView", , , "AgentID = '" & Me.cboLogin.Column(1) & "' OR AgentID Is Null",,,Me.cboLogin.Column(1)

Now it will be in form AgentView's Open Args

Exactly what I was looking for, thank you sir. I need to pick up a book on coding this stuff. >_<

Now in this agent view I want to place buttons that will apply a filter on the current form, drawing from this text box listing the user. I know I could use similar code to the above line, I just dont know the commands to do it within the same form or if this is even possible? I want to filter for records where the agentID matches the textbox with the userID, where the agentID is empty, and the record which hasnt been edited in the in the longest amount of time.

[ipisors]

I would recommend instead, if possible, rather than creating a table with usernames and passwords, to use the network logon username. This is a common mistake is access database authors creating an overly complex system where users have to create their own username and password.... Now sometimes that's necessary depending on your user set up (lack of a network and separate PCs).

But if your users are setup on a typical company network and they each log on using their own unique logon, then creating either usernames OR passwords is unnecessary and less secure.
Just use a brief code to get the current network username, which is 100% secure (to the degree you trust your IT department, but my point is, security becomes their responsibility), and no passwords at all are necessary.

After you do that, the answer to this question then becomes:
1) set up a table that simply saves the information of which logon id has access to the database, and/or has access to some other things in your DB.
2) call the GetUserID() function each time it's needed. (it runs instantaneously, so there is no need to save anything in a public variable, which may lose its value when untrapped errors occur).

Last but not least, if you insist on setting it up the way you are, I'd recommend using TempVars instead of a global variable....and even better than that, I'd recommend storing the value in an unbound / hidden textbox on a form that remains open as long as the database is open; either of these is more reliable and less prone to fail than a public variable.

[Dclassen89]

I would recommend instead, if possible, rather than creating a table with usernames and passwords, to use the network logon username. This is a common mistake is access database authors creating an overly complex system where users have to create their own username and password.... Now sometimes that's necessary depending on your user set up (lack of a network and separate PCs).

But if your users are setup on a typical company network and they each log on using their own unique logon, then creating either usernames OR passwords is unnecessary and less secure.
Just use a brief code to get the current network username, which is 100% secure (to the degree you trust your IT department, but my point is, security becomes their responsibility), and no passwords at all are necessary.

After you do that, the answer to this question then becomes:
1) set up a table that simply saves the information of which logon id has access to the database, and/or has access to some other things in your DB.
2) call the GetUserID() function each time it's needed. (it runs instantaneously, so there is no need to save anything in a public variable, which may lose its value when untrapped errors occur).

Last but not least, if you insist on setting it up the way you are, I'd recommend using TempVars instead of a global variable....and even better than that, I'd recommend storing the value in an unbound / hidden textbox on a form that remains open as long as the database is open; either of these is more reliable and less prone to fail than a public variable.

I think I will have to stick with the current login system for now, what are the advantages of storing the login in a separate form? The form I have it stored in currently will remain open as long as the user is logged in, it functions as a sort of dashboard so to speak.

[ipisors]

I actually posted a link to the code that gets the user id in my last post.

You can also use Environ("username") but it's much less reliable and very easy to spoof.

The specific "code" all depends on how you choose to set up your access? I mean how are you doing it - per control? per tab page? etc. Personally, I like to create databases with Tab controls as the primary, main menu. Not only does it keep things properly separate, but it looks professional and mimics the look of other professionally programmed applications that the world in general is used to seeing.

So if that was your case, you could code the Change event of the tab control to see what its value was (i.e., page index) - allow or disallow access.

How to code would be totally different depending on your specific choice of how to implement.

[Dclassen89]

Basically the db is setup to allow employees access to view different customer records via a main form after logging in, and perform various other actions like placing orders, security is not a huge issue. It is all currently setup in a main form, no tabs, records are assigned to specific employees and the employee can view the records assigned to them and assigned to no one. They can then place orders, take notes on a customer, navigate records via combo boxes and record selection buttons. The critical tables are stored to a back end db, which will have some management forms. I am unsure of the networking setup thats why I am taking this route for the time being.

[ItsMe]

...Now in this agent view I want to place buttons that will apply a filter on the current form...

I am not sure I understand how you are trying to filter your form. I use dynamic SQL strings to assign a specific RecordSource to the form. This method does not require using the filter.

Also, it seems that the AgentID field holds the elusive value you are including in your Open Args. In other words, you do not need to include Me.cboLogin.Column(1) in your open args because the value is already present in AgentID. If you do not have a control in your AgentView form that is bound to this field you can add one and then you will not need to use open args.

The following
DoCmd.OpenForm "AgentView", , , "AgentID = '" & Me.cboLogin.Column(1)
Will open the form so it is filtered to the AgentID. You can display this value to the user if you wish. If you choose to do so, I recommend you adjust the control's properties so the user does not have the capability to edit the value.

You can adjust the filter property of the form using a control button or control toggle. Something like

dim strID as string
strID = Me.AgentID

Me.filteron = false
me.filter = ""

if Me.ToggleControlName = -1 then
me.filter = "AgentID = '" & strID & "' OR AgentID Is Null"
else
me.filter = "AgentID = '" & strID & "'"
end if

Me.filteron = TRUE

[ipisors]

I guess my point is ... security is not a major issue you say, but the method you're using to get some security (tables and requiring users to create or maintain usernames and passwords- likely totally unsecured in the back end tables) is actually harder than the method I'm recommending.

Basically the db is setup to allow employees access to view different customer records via a main form after logging in, and perform various other actions like placing orders, security is not a huge issue. It is all currently setup in a main form, no tabs, records are assigned to specific employees and the employee can view the records assigned to them and assigned to no one. They can then place orders, take notes on a customer, navigate records via combo boxes and record selection buttons. The critical tables are stored to a back end db, which will have some management forms. I am unsure of the networking setup thats why I am taking this route for the time being.

[Dclassen89]

I guess my point is ... security is not a major issue you say, but the method you're using to get some security (tables and requiring users to create or maintain usernames and passwords- likely totally unsecured in the back end tables) is actually harder than the method I'm recommending.

I guess I see what you're saying. I will ask about how the network is setup for the client and see if this could work.

[ipisors]

Cool , if you decide to implement and get stuck let us know.

This is how I think of it:

- First, imagine someone finding your back end tables, and seeing all the passwords in plain english, unless you use a Hash function to encrypt them or pw protect the back end, either of which require CONSIDERABLE coding to 'get around' when deploying the front end and maintaining the pw's..

- Now, imagine the fact that if users have network logons, likely they log on with that information each and every time....the rules against credential-sharing are entirely the known responsibility of the users, and the security of network logons is entirely the known responsibility of IT.

- Last, imagine it is as easy as coding:
Select Case Getuserid()
case "bjohnson","shamilton"
Docmd.Openform..
case else
msgbox "sorry, no access to manager form"
End Select

Happy coding!