Login Issue By Closing Access From Taskbar

[Micron]

No need to apologize. I was just pointing out that there were now 2 votes for that approach. Post 4

I would not bind the form but use code to populate these fields.

Besides, if the current code is causing the problem, there's no guarantee that an unbound form will solve the problem if the same approach is taken.


EDIT - actually, I wouldn't use a login form at all as I mentioned.

[Gicu]

I modified a bit your code, could you give it a try? Regarding the empty records, do you start the form in data add mode? Any code in the Load or Open events?

Private Sub cmdLogin_Click()
Dim validCredentials As Integer
Dim userLevel As Variant
Dim ID As Integer


validCredentials = DCount("Username", "[tblUser]", "[Username] ='" & txtUsername & "' AND [Password]='" & txtPassword & "'")




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




If validCredentials = 1 Then
        userLevel = Nz(DLookup("UserSecurity", "[tblUser]", "[Username]='" & Me.txtUsername & "'"), "")  'was 0 on the next line you look for a string
        If userLevel = "Admin" Then
            Me.txtLoginDateTime = Now()
            Me.Dirty = False  'DoCmd.RunCommand acCmdSaveRecord
            Me.Visible=False  'DoCmd.OpenForm "Login", acNormal, , , acFormEdit, acHidden 
            DoCmd.OpenForm "Main Menu_admin"
Else
            Me.txtLoginDateTime = Now()
            Me.Dirty = False  '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) And IsNull(Me.txtPassword) Then
	Me.Undo
    Exit Sub
Else
    [Forms]![Login]![txtLogoutDateTime] = Now()
End If


End Sub

Cheers,

You might want to review my free sample http app that has the auto-logon feature suggested by Micron and also a nice custom chat feature you could use to ask your users to get out for maintenance://forestbyte.com/ms-access-utilities/fba-ms-access-custom-chat/

You can also force them out adding a table to the back-end with a Yes\No field which you would check when you want them out; I usually implement this in conjunction with the "shut down on idle" code I sent you earlier. Let me know if you're interested to see it and I'll dig it out.

Cheers,

[data808]

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.

Yes click code is irrelevant when it comes to the Login button or the Quit button that I have on the Login form when closing the app by taskbar. And yes, you are correct again that the autonumber is assigned to a record that has no values saved. Every field is blank for that record when I don't type anything into any fields on the Login form and just close app by taskbar. It will save the record with no values. I wish it would at least skip that autonumber the next time I start typing in the login form. However, what doesn't make sense is that the form is not even dirty if I do not type anything into the login fields so I don't understand how it would save this blank record in the first place. It's very odd.

I will try and take a look at the opening events to see if I have any code written and will report back with what I find.

[data808]

Ok here are the event codes I found that may be relevant to the opening sequence of my database. The first form that opens is a splash screen. Kind of like a loading screen for a few seconds. Here are the events that trigger for the splash screen:

Private Sub Form_Open(Cancel As Integer)

DoCmd.ShowToolbar "Ribbon", acToolbarNo
fActivateControlBox (False)
fSetAccessWindow (SW_SHOWMINIMIZED)


End Sub

Private Sub Form_Timer()

DoCmd.Close
DoCmd.OpenForm "Login"


End Sub

Then once the splash screen closes and the login form opens, here is the code that I found for the login form:

Private Sub Form_Current()

Me.txtUsername = UCase(Me.txtUsername)


End Sub

Private Sub Form_Open(Cancel As Integer)

DoCmd.GoToRecord , , acNewRec
Me.txtUsername.SetFocus


End Sub

Private Sub Form_Close()

If Me.Dirty Then
    Me.Undo
    Exit Sub
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) And IsNull(Me.txtPassword) 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

Not sure if the close event does anything because I just added that to see if it would resolve the issue of saving blank records but nothing changed since I added it so that probably can be removed. I was just trying to insert more Me.Undo lines because that seems to be the function that takes care of unwanted saved records if the user clicks the Quit button on the login form which is simply this:

Private Sub cmdQuitApp_Click()

Me.Undo
DoCmd.Quit


End Sub

When the user clicks the Quit button then no record is saved regardless if I type credentials or not. So whether the form is dirty or not, the quit button (probably the Me.Undo) makes it so that no record is saved. But if I close the app by taskbar, no matter what, if I type credentials or not, the record will save reflecting what I type or don't type. What doesn't make sense is that if a form is NOT Dirty, how can it save it as a record to begin with? How can an autonumber be assigned to a record if the user doesn't type anything to make the form Dirty?

[Micron]

Nothing there stands out as the cause. I agree that unless a field is edited, there shouldn't be a record with only an autonumber even if you have a field with a default value. That would cause you to skip an's if you start a record though, which is why I wanted to make sure the an was actually there. I'd run a query on the table with a criteria row for each field using "" as criteria (not on autonumber field of course, but include it in the query). If you get any records, the null tests you are doing are insufficient because the fields contain zls and not nulls.

You could also copy db, remove sensitive data & all tables/reports etc. not required for this. Then compact/repair the copy, zip and post here for analysis.

[Welshgasman]

Surely by the time you get to the close event, the record would have been saved and thus no longer dirty?

Perhaps take a look at this video. https://screencast-o-matic.com/watch/c3j1b6VZGNC

https://stackoverflow.com/questions/...s-in-ms-access

[Micron]

Surely by the time you get to the close event, the record would have been saved and thus no longer dirty?

Close event was just an add-on trying to fix the problem, I think. I too thought it unnecessary because of the Unload event but didn't say so because of that.

[Gicu]

@data808: I think the Current event dirties the form and creates the empty record....
The Unload event doesn't seem right, I would suggest you try the one I gave you in post #17 and see what happens. Also try the modified code for the login button.

Cheers,

[Micron]

It would start a record, but this should undo it?

Private Sub Form_Unload(Cancel As Integer)

If Me.Dirty Then
    Me.Undo

[Welshgasman]

It would start a record, but this should undo it?

Private Sub Form_Unload(Cancel As Integer)

If Me.Dirty Then
    Me.Undo

Surely the same applies as I mentioned for the Close event?
https://support.microsoft.com/en-us/...n-us&ad=us#bm3

Easy enough to check. Comment out the OnCurrent uppercase line and put it in the AfterUpdate of the control?

[Gicu]

It should be in the AfterUpdate anyway, unless the username comes pre-populated from a local settings table holding the last user (which it should as the users should not have to type their username every time they log on).

Cheers,

[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?

Just to clarify the scenarios:

Backend Table consists of Username, Login Date/Time, and Logout Date/time fields.

SCENARIOS
1. User is looking at the login form (not hidden). Does not type anything and closes app by taskbar. Record saved as blank record. No username, no login date/time, and no logout date/time values in backend table.

2. Same as scenario 1 but instead user clicks the Quit button instead of closing by taskbar. Record is not saved. However, autonumber was used because the next time a record is saved the autonumber will be skipped. I am totally fine with this.

3. User is looking at the login form (not hidden). Types username then decides to close app by taskbar instead of completing login. Record saved with just username value and no login and logout date/time values. I wish the Unload event would trigger the Me.Undo so no record is saved at all.

4. User looking at the login form (not hidden). Types username and password. Clicks login button. Login form is now hidden and opens main menu form. User closes app by taskbar. Record saved with all info. (Username, login date/time, and logout date/time) Login date/time triggered Now() function from Login button click and the Logout date/time triggered Now() function from Unload event of the Login form.

5. Same as scenario 4 but user clicks the Quit button instead of closing app by taskbar. Record save results are the same with all info. (Username, login date/time, and logout date/time)

So if you look at scenario 1 and 2, this verifies that the form is somehow Dirty even when the user does not type anything into the form. This is why even if the user clicks the Quit button to close app and the Quit click event has Me.Undo, it doesn't stop the autonumber from being assigned because the form was Dirty in the first place. I know this because the next record that is saved, the autonumber will be skipped by 1 count. So figuring out why this form is Dirty in the first place may help find the answer to prevent blank records from being saved.

If you look at scenario 4 and 5, these scenarios give the results I am looking for regardless if the user closes by taskbar or uses the Quit button. My theory is that when the login form is hidden and the main menu becomes the main focus for the user, if they close the app by taskbar, they are immediately pulling the plug on the main menu, not the login form. What that means is that the main menu will close immediately and not have time to trigger any events. Then the hidden login form will follow but the fact that the login form is following, that gives it enough time to trigger that Unload event that is able to do the Now() fucntion for the logout date/time stamp. This may explain why this Unload event does not trigger if you close the app by taskbar in scenario 1 or 2 because you are pulling the plug while the login form is the main focus and not hidden.

Sorry if it's confusing but basically we have 2 problems. 1, being that the login form is somehow Dirty without the user typing anything into it, and 2, the Unload event is triggering inconsistently. Unload event seems to only trigger for scenarios 4 and 5 and that is when the login form is hidden.

[Gicu]

Can you please create a small sample with just the login table, login form and switchboard and include any necessary objects (such as AutoExec macro) to make this work so we can see\test the scenarios. I have not yet see the entire code for the login form, how is it started (autoexec macro vs. startup form properties), etc.
The code you had originally had some issues that I tried to change\correct (for example you were opening the form again hidden using OpenForm method instead of simply setting the Visible property to false for the current instance). Have you tried any of the code changes I suggested?

Cheers,

[data808]

Nothing there stands out as the cause. I agree that unless a field is edited, there shouldn't be a record with only an autonumber even if you have a field with a default value. That would cause you to skip an's if you start a record though, which is why I wanted to make sure the an was actually there. I'd run a query on the table with a criteria row for each field using "" as criteria (not on autonumber field of course, but include it in the query). If you get any records, the null tests you are doing are insufficient because the fields contain zls and not nulls.

You could also copy db, remove sensitive data & all tables/reports etc. not required for this. Then compact/repair the copy, zip and post here for analysis.

That is a great idea. I actually found out the hard way that there is a difference between Null and "". I may look into this if I can't find out what is causing the form to be dirty.

[data808]

Surely by the time you get to the close event, the record would have been saved and thus no longer dirty?

Perhaps take a look at this video. https://screencast-o-matic.com/watch/c3j1b6VZGNC

https://stackoverflow.com/questions/...s-in-ms-access

Yes if the user clicks the login button, that is where the DoCmd.RunCommand acCmdSaveRecord resides. I just added the Close event code (me.dirty and me.undo) for repetition in hopes that the me.undo would trigger somewhere because the Unload event didn't seem to do anything when closing the app by the taskbar.