Experts find patterns for common tasks and they use those patterns unless/until something better is discovered. So, if I know a method that works in some cases and another that works in all cases, am I going to decide each time I need to use that method which to use? No, I'm going to always use the more generic method so I don't have to worry about something changing in the future. Think of it as defensive programming. The restrictive method isn't necessarily wrong but the generic method is safer. The less I have to think about and the fewer decisions i have to make when coding, the faster I can work and the better the product will be. And then there is the consistency of it which means that people reading my code won't be surprised.
The designers of Access made form events with specific tasks in mind. Sometimes, your code will work in multiple places but usually, it is constricted in some way if you choose an event different from the one the designers envisioned. Events are NOT random. They all have a purpose. If you learn to understand the purpose, you are more likely to automatically choose the correct event without having to think about it.
The Load event runs once and only once after the RecordSource is loaded.
The Current event runs once for each record you scroll to or add.
Since you currently constrain the form to a single record, you could use either event but if sometime down the road, you or someone else removes the single record constraint, you'll end up with a bug. If you want to do something similar in a new form that doesn't have the single record constraint, you will most likely use the method that worked in the past and you'll spend a lot of time trying to figure out why it doesn't work now.
The two most important events for bound forms are the
BeforeUpdate event which is the LAST event that fires BEFORE a record is saved. Think of it as the flapper at the bottom of a funnel. If the flapper is open, the record saves. If the flapper is closed, the record is not saved but it stays dirty unless you use Me.Undo which I strongly recommend against. It is annoying to the users to have you undo all their typing just because he made one tiny error so the only time I ever use Me.Undo is if I am not going to let him update at all. But in that case, I put the security validation in the on Dirty event. If the user isn't authorized to change a record, I tell him as soon as he types a single character and I use Me.Undo to back out his change. Using this technique (a pattern), I never have to futz with the form's "Allow" properties so it takes less code.
and the Current event.
I've mentioned a few times that I once removed something like 5,000 lines of code from an application built by a developer who had no clue what event should be used for validation code. At some point he discovered that his error messages were being displayed but the bad data was still being saved so he put validation code into each control's AfterUpdate, LostFocus, On Change, mouse up, and several others and nothing worked. So he started adding validation code for other controls. So for the first control he validated that control in all the mentioned events. For the second control, he validated the first control and the second control in all the mentioned events. For the third, he did 1,2,3, etc. Some forms had as many as 50 controls so we ended up with a whole lot of code that threw a whole lot of error messages but never stopped the save. All he needed was a couple of lines of code for each control in the CORRECT event. That event is the FORM's BeforeUpdate event. In that event you can actually stop the record from being saved if you find an error. In some cases, you can put validation code in each control's BeforeUpdate event. But the problem is that f the control never gets the focus, the BeforeUpdate event never fires so you can never validate the presence/absence of a value. You can only do that in the FORM level BeforeUpdate event. So again, it's not wrong to use the control's BeforeUpdate event but you will still need code in the FORM's beforeUpdate event if you want complete validation. On the rare occassions where I use the control's BeforeUpdate event it is because I want an error message displayed immediately before the user fills out the rest of the form. If I'm not going to let him save a record because the SSN is a duplicate for example, I may as well tell him early rather than late. But the code to ensure that there is an SSN is still in the form level event.
