Multi user login screen - question about tracking logged in users

[anewuser]

Hi,

I currently have a working multi user login form which automatically directs users to the relevent forms e.g. general staff have access to a form called staff1 and staff2 whereas managers have access to a form called manager1. I have used the following code:

Option Compare Database
Private Sub Login_Click()
UserName.SetFocus
If UserName = "Staff1" And Password = "Staff1" Then
MsgBox "Welcome"
DoCmd.Close
DoCmd.OpenForm "Staff1"
ElseIf UserName = "Staff2" And Password = "Staff2" Then
MsgBox "Welcome"
DoCmd.Close
DoCmd.OpenForm "Staff2"
ElseIf UserName = "Manager1" And Password = "Manager1" Then
MsgBox "Welcome, please exercise caution when changing query or table conditions", vbInformation, "CDSignatures"
DoCmd.Close
DoCmd.OpenForm "Manager1"
Else
MsgBox "Please re-enter Username and Password"
End If
End Sub
 

My question is how can I track users once they have logged in. I have a database which tracks data that has been editted from the main database and I would like to know how to show which user has done this.

Thanks in advance.

[anewuser]

Hi Everyone, I know it has been a while since my last post and this is because everything now works fine and i haven't had the time to get back online to thank you all for all of your help.

[NeoPa]

I'm pleased to hear that, but it may be helpful to anyone reading the thread if you posted an explanation of why it wasn't working and what you changed at that point to make it work.

[anewuser]

I was able to login as normal using the code from post 35. However, it was not updating the usyscurrentuser table. I fixed this by changing the source of the form from nothing to the usyscurrentuser table. This worked, now when I log in it adds a new record into this table. Probably not the best way to sort the problem but it has worked and I am happy with it.

[NeoPa]

Probably not a bad solution as it happens. It won't normally add a new user BTW, but update the existing one. At least after the first time. This is lucky, as if it added one it would be fundamentally useless to the process.

Z:
It is a known bug in the editor (at least to those of us that do a lot of programing) the MS doesn't seem to (or care to) want to fix.

I consider myself reasonably experienced in that area, but I hadn't heard that before ;-) I'll certainly bear it in mind in future. It does mean the code needs to be recompiled anyway - unless the object is closed without saving I suppose. Food for thought.

[zmbd]

Usually happens when the breakpoint trips and/or stepping thru code: then code is edited while in the debug state. Google "phantom break point." Been around since at least 97 when I first encountered it... wouldn't be surprised if there isn't something here on BYTES :)
(found one: http://bytes.com/topic/access/answer...en-starting-pc :)

[NeoPa]

Oh that issue. I've had that a few times. Like one of the posters in the linked thread, I will simply add an edit, recompile and save. Typically though, although I will change code while running during the development cycle, I will redo it for release, and I never save an object with any breakpoints set, for that reason. Sometimes, with an object that is already supposed to be ready for release, but I have to make small tweaks to it, I'll close the object without saving, but after I've copied all the code to the clipboard, then reopen it, replace the code with the new, and close and save it then.

I've never seen this talked about before though. I just came up with my work-arounds after experiencing the problem a few times.

I still use breakpoints though, just within the parameters explained above. Clearly it makes sense to advise against relying on them for general consumption though. Good work as usual :-)