Login Issue By Closing Access From Taskbar

[data808]

I am having a problem with users closing Access by right clicking the Access icon in the taskbar and then closing it that way. I have some VBA in the On Unload event that is supposed to take care of this scenario but it doesn't seem to work every time. When the user logs in, it creates a time stamp of when they logged in. When they log out it does the same thing to show what time they logged out. However, the user needs to use the login/logout/quit buttons I have created throughout the data base since that is how the time stamps will trigger. I also have some VBA in other events like the On Unload event to trigger time stamps. If the user closes Access by the taskbar then it becomes inconsistent. I thought that even though the user right clicks the Access icon in the taskbar to close the application, this would count as an Unload event. I think I have also tried the On Close event and similar issues will occur. Right now I have time stamps sometimes missing or totally blank records of the logins saving with no data values entered.

Is there an event that will still trigger 100% of the time even if the user closes Access from the taskbar?

If this doesn't work then I'll provide more info.



Thanks for the help.

[Micron]

I think the answer is to create a simple form, open it hidden when the app opens. If you cancel the form close, AFAIK the app won't close either but I think that might be irritating to users, so I'd probably put the time stamping code in the unload or close event of the hidden form.

[data808]

I think the answer is to create a simple form, open it hidden when the app opens. If you cancel the form close, AFAIK the app won't close either but I think that might be irritating to users, so I'd probably put the time stamping code in the unload or close event of the hidden form.

My apologies. That is basically what I am doing right now. So the user fills in credentials in the login form, I also have login date/time and logout date/time hidden text boxes in this login form that auto-fill once they do the actions needed to trigger it.

So the way it works is the hidden login date/time text box will auto fill once the user clicks the login button. It will also make the login form hidden because this form is also used throughout the database to fill in the "Signed In As:" text boxes throughout the database to indicate which user's session is logged in. So it's always referencing back to this hidden login form during their session.

As for the hidden logout date/time text box on the hidden login form, the way this works is the auto date/time stamp will trigger when the hidden login form closes because I have VBA in the On Unload event. Closing of this hidden login form occurs when the user clicks one my of logout/quit buttons or if the user right clicks the Access icon in the taskbar and closes the app that way. I thought the On Unload event would be enough to handle all scenarios such as this because regardless how they choose to close the app, it technically still has to close the hidden login form.

However, when checking the table of all the user login/logout date/time records, I see occasional missing data. What I mean by this is that sometimes the record will show only parts of the record. The record basically consists of Username, Login Date/Time, and Logout Date/Time. So most of the missing data records will not have the logout date/time but will have the username and login date/time filled in. But I also did see some records that were saved that are completely blank. Meaning, no username, no login date/time, or no logout date/time filled in but I can tell it was saved because it has a primary key assigned to the record. So for those, my Me.Undo did not trigger. The scenario that covers the Me.Undo most of the time is when the user starts to fill in the login credentials but changes their mind before completing the login process and quits the app while the login form is Dirty as I would not want unsuccessful login attempts to be saved.

Lastly, I also do see records with missing login date/times but it has the logout date/time filled in but that type of missing record data tends to be more rare. It seems that my Login button takes care of most scenarios without issues. It's mostly logging out that missing data occurs and so that is why I also think the user is right clicking the Access icon in the taskbar to close the application as I have also tested it and was able to replicate some of those issues of missing data records if I close the app that way. For some reason when the user closes the app by taskbar, the On Unload doesn't work consistently. It will only work if the user uses my logout/quit buttons I have throughout the database. So basically they need to use the interface of the forms I created to trigger the On Unload event of the hidden login form.

So my goal right now is to figure out if there are other events that could handle this type of scenario of closing by taskbar or somehow prevent the user from closing the app by the taskbar. If you have any other suggestions, then I am all ears.

Thanks for your time.

[Micron]

I also have login date/time and logout date/time hidden text boxes in this login form that auto-fill once they do the actions needed to trigger it.

Perhaps those actions are being circumvented, whether by unforeseen user actions or not.
If you "auto fill" a bound control and don't ensure the record is updated that might be another issue.

some records that were saved that are completely blank

I would not bind the form but use code to populate these fields. In fact, unless your users are sharing a Windows login, I would dispense with the login form altogether in favour of just getting their user credentials from a table based on their Windows login id. If anyone opens db and they're not in the table, they don't get in. If it's possible to spoof Windows login id, it would take the most determined hacker within your organization. This also eliminates all the db password management junk, such as forgotten passwords. User profile data can then come from TempVars rather than an open form.

Of course, not much can be done if users are using Task Manager to shut down Access or if pulling the plug so to speak.

[Gicu]

You could also follow the suggestions in this thread and update the logout date\time every 15 minutes or so, so even if the Unload event doesn't fire you are accurate to within your update interval:
https://www.access-programmers.co.uk...e-exit.279365/

Cheers,

[data808]

Perhaps those actions are being circumvented, whether by unforeseen user actions or not.
If you "auto fill" a bound control and don't ensure the record is updated that might be another issue.
I would not bind the form but use code to populate these fields. In fact, unless your users are sharing a Windows login, I would dispense with the login form altogether in favour of just getting their user credentials from a table based on their Windows login id. If anyone opens db and they're not in the table, they don't get in. If it's possible to spoof Windows login id, it would take the most determined hacker within your organization. This also eliminates all the db password management junk, such as forgotten passwords. User profile data can then come from TempVars rather than an open form.

Of course, not much can be done if users are using Task Manager to shut down Access or if pulling the plug so to speak.

Yeah I think I need to try and think of more unforeseen possibilities and also add some Docmd.Save lines to ensure the record is updated. The coding to go by the Windows Logins sounds a bit beyond my ability.

I'll try and address one problem at a time and maybe you can shed some light as to what is happening and also if there are possible remedies for it.

First off, I opened the application and the login form loads up. I don't type any credentials and close by taskbar and the record is saved blank. Is there an event that I could use to handle taskbar closing? You mentioned task manager closing or even power outages, is there something that works for those cases as well?

[Micron]

The coding to go by the Windows Logins sounds a bit beyond my ability.

Very easy. Look up fosUserName. I can't recall if you need to worry about 32 vs 64 bit or not - it depends on the API calls.
There is not much you can do about a user "pulling the plug". My suggestion would be to post a db copy with some scenarios that you know/think cause issues. I suppose we could review all the posts to see what they are, but a summary would be nice. See "how to attach files" at the top of the forum window if you're not familiar with the requirements.

[data808]

You could also follow the suggestions in this thread and update the logout date\time every 15 minutes or so, so even if the Unload event doesn't fire you are accurate to within your update interval:
https://www.access-programmers.co.uk...e-exit.279365/

Cheers,

That's a great idea. Will check it out. Would it be overkill on system resources if you made it update more frequently? Like say, every 3-5 minutes? I would think there is a reason why not just have a live clock updating every second and if the electricity goes out then it will have the last second it was online. But even every 15 mins is not bad too if that is the most frequent interval recommended.

[data808]

You could also follow the suggestions in this thread and update the logout date\time every 15 minutes or so, so even if the Unload event doesn't fire you are accurate to within your update interval:
https://www.access-programmers.co.uk...e-exit.279365/

Cheers,

I gave it more thought and one of the main reasons why I created this Login Date/Time stamp was to know which users were logged in when I was waiting for everyone to logout to make some kind of update. The way I do this is by checking the table that holds these login/logout records and if the logout date/time stamp is empty then I know they are still logged in. If I apply the idea of updating the logout time every 15 mins. that will give me inaccurate info as to who actually logged out.

Thanks for the suggestion though.

[data808]

Very easy. Look up fosUserName. I can't recall if you need to worry about 32 vs 64 bit or not - it depends on the API calls.
There is not much you can do about a user "pulling the plug". My suggestion would be to post a db copy with some scenarios that you know/think cause issues. I suppose we could review all the posts to see what they are, but a summary would be nice. See "how to attach files" at the top of the forum window if you're not familiar with the requirements.

Just found out something interesting.

So like mentioned before, if I open the application and the login form loads and I don't type in any credentials and close the application by right clicking and closing Access by the taskbar, it will save a blank record. However, if I type in credentials and actually login then close the app by taskbar, it will of course show the login date and time but it also saved the logout date and time as well. Why is it saving the logout date and time only if I login successfully as opposed to not logging in? Here is the code I have in the Login button click event and the On Unload event for the login form:

Private Sub cmdLogin_Click()
Dim validCredentials As IntegerDim userLevel As Variant
Dim ID As Integer
validCredentials = DCount("Username", "[tblUser]", "[Username] ='" & txtUsername & "' AND [Password]='" & txtPassword & "'")


ID = DLookup("UserID", "tblUser", "Username = '" & Me.txtUsername.Value & "'")


If validCredentials = 1 Then
        userLevel = Nz(DLookup("UserSecurity", "[tblUser]", "[Username]='" & txtUsername & "'"), 0)
        If userLevel = "Admin" Then
            Me.txtLoginDateTime.Value = Now()
            DoCmd.RunCommand acCmdSaveRecord
            DoCmd.OpenForm "Login", acNormal, , , acFormEdit, acHidden
            DoCmd.OpenForm "Main Menu_admin"
Else
            Me.txtLoginDateTime.Value = Now()
            DoCmd.RunCommand acCmdSaveRecord
            DoCmd.OpenForm "Splash Screen Load"
        End If
    Else
        MsgBox "Invalid Username Or Password!", vbExclamation, "UNAUTHORIZED!"
        Me.txtPassword.SetFocus
    End If
End Sub

Private Sub Form_Unload(Cancel As Integer)

If Me.Dirty Then
    Me.Undo
    Exit Sub
End If


If IsNull(Me.txtUsername) Or IsNull(Me.txtPassword) Then
    Exit Sub
Else
    [Forms]![Login]![txtLogoutDateTime] = Now()
End If


End Sub

[data808]

Very easy. Look up fosUserName. I can't recall if you need to worry about 32 vs 64 bit or not - it depends on the API calls.
There is not much you can do about a user "pulling the plug". My suggestion would be to post a db copy with some scenarios that you know/think cause issues. I suppose we could review all the posts to see what they are, but a summary would be nice. See "how to attach files" at the top of the forum window if you're not familiar with the requirements.

Nevermind. I think I see it. Its the line:

If IsNull(Me.txtUsername) Or IsNull(Me.txtPassword) Then
Exit Sub

I think I put that line there to handle if the user decides not to login but started typing one of those credentials. I think to remedy this I would also have to add this above it:

If IsNull(Me.txtUsername) And IsNull(Me.txtPassword) Then
Me.Undo
Exit Sub

[data808]

Added the line to the On Unload event:

If IsNull(Me.txtUsername) And IsNull(Me.txtPassword) Then
Me.Undo

and I get the same results. So now my theory is that the login form, while open and unhidden or viewable to the user, if they close the app by taskbar while looking at this login form, regardless if they type credentials or not, it will save the record because it's like pulling the plug on this login form. I have tested not typing credentials which = blank record and if I type say username with no password, it will save just the username as the record and so forth.

Now if I login and the form becomes hidden, then I close the app by taskbar, it will close the menu form that is now the main focus and then probably closes the hidden login form split seconds after. My guess is that the login form has time to register it's Unload/Close event because the user actually "pulled the plug" on the Main Menu form instead. that's why it has enough time to save the Logout Date/Time data for the record. That is what I think is happening.

So basically whatever form you are looking at, is the form you are pulling the plug on if you close by the taskbar method. If there are any hidden forms, they will subsequently follow in closing out and this gives these hidden forms enough time to trigger the On Unload and On Close events.

Does that make sense?

[Welshgasman]

Perhaps this is a time an unbound form would be useful?

[Micron]

I don't type in any credentials and close the application

In that case the click code is irrelevant, yes? Something else must be starting a record before that. You say that happens because there is an blank record with an autonumber and not because an autonumber is skipped right? Something isn't clear/right about that. It would appear that your unload code should provide an exit time stamp so how could the record be blank? I'd say only if the controls are not null but are zls. Still, something not shown must be starting that record in the first place.To continue looking, try stepping through the code right from the opening of the db. I think we'd have to see the db if you can't find it.
Re: the code - Rather than getting the count then getting the userlevel, just DLookup the user level?

@WGM; unbound form was suggested, as was no form at all.

[Welshgasman]

Sorry, I searched quickly and nothing found.
If I search now, my unbound is the first found?