On Dirty

[missinglinq]

When a record is accessed, the first time any bound control on a bound form has data entered/edited, the form becomes Dirty and the OnDirty event is executed. Sounds simple, but this is Access, so naturally it isn't!

This occurs only the first time! If the same control has data entered a second time or another control has data entered, the form is still Dirty, but the OnDirty event will not execute again.

If data is entered into a Control thru VBA code, say

Me.MyTextbox = "Some Value"

or any other way except physically entering the data, the form will be Dirty, but the OnDirty event will not execute!

If data is entered into a Control thru VBA, as noted above, the form will be Dirty but subsequent physically entering data into the form will not cause OnDirty to execute.

Lastly, data entered by way of a control's Default Value while it 'enters' data, does not make the form Dirty and it does not cause the OnDirty event to fire.

Linq ;0)>

 

[mloucel]

S... no wonder.. damn, any solution to this?

 

[Isaac]

Meaning what?

 

[pbaldy]

What specific problem are you trying to solve?

 

[mloucel]

Sorry ALL, I've been taking a class in ACCESS, but is so frustrating, it teaches you all the basics and some advanced techniques, but when you apply that to the real life of a real application is sort of worthless, so many holes, I explain that to our teacher and he really doesn't care, he says "You'll learn from the basics" SURE, you can teach someone to drive a car, but try with an 18 wheeler and your doom.
I would love to see a class that starts with basics.. OK, then create a full blown application, where Forms are used to enter the info, correct the info, mix tables of all sort, queries, and teach step by step what are the different techniques, but I live in a fantasy world.
I'm sure many of you agree with me, this is no way of teaching, here it is how FORMS are created. (period) compared to let's create a form that is going to enter data to 3 different tables linked, verify certain fields of the data don't exist on the current database, to add or, if data exists, then display the existing data, we will use a sub form, then some tabs and use combo boxes, buttons, etc.
That's a class/book/video I will buy, but so far, here is the ribbon, let's create a table, let's create a form from the table, let's add data to the table,..
SORRY for my rant, but is so frustrated, even the "ADVANCED" classes teaches you nothing of a real life Application, I just got a book recommended here that it looks very promising, besides the usual STUFF, it may go deeper creating an application and developing it fully, to reports easy and complex, I'll see what the future shows me.

Maurice.

 

[Gasman]

I know where you are coming from.

I have to use a Landlord computer system. They have video tutorials and a knowledgebase that helps you get to grips with the 'basics' of the system.
However it does not explain why you have to select certain entries and what happens when you do not. :-(

I am finding that out as an entry does not appear where I expect it to.

I think there are a good few events that are not executed if the control is modified by VBA instead of a user.? Not aware of the dirty event issue, but then I have never used it, so it has never affected me.

 

[Pat Hartman]

I know this is old but for some reason it popped onto my feed.

When you dirty a control with VBA, it does flag the form as dirty which is excellent but it does not cause any control events to run. The only event you can rely on 100% to validate data is the Form's BeforeUpdate event. It can never be bypassed. It always runs when you or Access decides to save the data and Access takes it as a personal mission to not lose data so it saves data in sometimes unexpected (to the uninitiated) places. But regardless of what prompted the save, if the record is dirty, then the Form's BeforeUpdate event is the last event that runs before the record is saved. In this event, you validate data and cancel the save if anything is missing or invalid.

Here's a video if you have some time. It mentions this idiosyncrasy in Access form processing.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[Isaac]

Good point Pat.
I do support the strong usage of form's BeforeUpdate event.

Sometimes I'll put "mini"-validations in other places, BUT, they're never the only way I validate that particular thing...it's also validated in BeforeUpdate (usually).

For example, if someone enters an Order Number that has been Locked by management, I might pop-up a validation to stop them only because it's convenient, and saves them 20 minutes of entering the wrong information before finally getting tackled by the BeforeUpdate security guard.

Or, if someone enters something invalid, I might turn it red early on.

Any of these latter two examples might involve a controls Exit or Change events.

But the BeforeUpdate is the King of validating at the most serious level, whereby "This must (or must not) go in my SOR"

 

[Pat Hartman]

I agree. Sometimes you want to warn the user immediately to avoid wasted time if you are not going to allow the record to be saved due to duplication of a required field or something like that. When I decide to validate early in the control's BeforeUpdate event, I generally put the validation in a procedure so I can call it from both the control's BeforeUpdate event ad the form'[s BeforeUpdate event. That way I get to write it once and test it once but use it from multiple places. I almost never call event procedures from other event procedures because I don't want to make that kind of unexpected dependency. When the call is to a standalone sub, it is CLEAR that the code could be called from a different procedure. It is unexpected (although not wrong) when you reuse event procedures.

 

[Pat Hartman]

I just updated the Bad Business thread to include a second video which talks more about control events.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk