Solved Actions to take before move to a different record in a form

[The_Doc_Man]

Yes, forcing the "Dirty" flag to FALSE would force an update and trigger all update-related FORM events.

 

[vhung]

I'm not sure that "BeforeUpdate" satisfies my need. If I'm reading correctly, "BeforeUpdate" is executed anytime any field on the form is changed? My dilemma is I need to trigger the email after all four address fields have POSSIBLY been updated. When all four fields have been changed, that's easy; I can check for that condition and trigger the email anytime while I'm on the current record. However that's not always the case; an individual could move to a new address in the same city and/or state, in which case the all-four-fields-changed trigger doesn't work. I can only trigger the check once the user leaves the current record.

I think I'm stuck.

quite hard
>address, city, state, and ZIP code.
>using "BeforeUpdate" could be possible, where there is 1 field that received your old "address, city, state, and ZIP code" as field1
>could be the other field received your new "address, city, state, and ZIP code "AfterUpdate" as field2
>in a quick way: could use messagebox where; field1 and field2 should be measued by its length; if f1=f2 maybe unchange; but if f1 is not = f2 then has changes
>others use tag

 

[arnelgp]

dim tfEmail As boolean

private sub form_beforeupdate(cancel as integer)
    tfEMail = (AfterFullAddress <> BeforeFullAddress)
end if

private sub form_afterupdate()
    if (tfEMail = True) Then
        'your code here to email it
    end if
    tfEMail = False
end sub

as proposed, do it on the Form's Before Update event.
and since it is a Validation event, i would try to make the code
short:

 

[arnelgp]

mr.vhung how are you?
filipino?

 

[arnelgp]

i am! and also the famous theDBGuy!

 

[arnelgp]

taga bulacan ako, si db nasa estate. ikaw?

 

[arnelgp]

nagka usap din kmi ni dbg, taga-Caloocan xa.
kaya pala un mga form no, pang lgu?!
ok, baka ma-huli tau.

 

[KACJR]

oh my goodness
>i'm glad
>both of you arnelgp and the theDBGuy, wow
>you've been my light in AWF

I'm honored that both of you have been helping me!

 

[KACJR]

Well, the original developer must have had some serious trust issues. I think I disabled close to 50 "Dirty=false" statements. So "BeforeUpdate" now seems to be doing what it is supposed to do.

One last anomaly, though. When I move to a new record, it appears that "BeforeUpdate" is triggered before the form is actually rendered. I looked for more "Dirty=false" statements but can't find any. It's not doing any harm because the address hasn't been changed at this point, but it seems unusual.

 

[vhung]

I'm honored that both of you have been helping me!

thanks for the recognition
>good luck with your project

 

[Isaac]

When I move to a new record, it appears that "BeforeUpdate" is triggered before the form is actually rendered. I looked for more "Dirty=false" statements but can't find any. It's not doing any harm because the address hasn't been changed at this point, but it seems unusual.

That sounds normal to me. The instant that you start going to a different record, Access is saving that current record, which triggers the event.

Isaac,
Are you really willing to knowingly write code that will fail under well known conditions despite their lack of frequency?

Not sure what you mean by well known condition. As I pointed out before, odds also exist that your suggestion of variables could result in an inaccurate result, too. Neither of our suggestions was 100% certain never to produce inaccurate results. I guess if either of us wanted to get to the "zero chance of inaccuracy" spot, then we would both have suggested a table-driven method only...

(You could also claim that when a SQL server transaction is committed, that's "not to be fully trusted" yet, because the server room might blow up after that point but before the log checkpoint, but most people are good at the 'committed' point) : )
So that's my take on it.

But, out of curiosity, can you give me an example of a "well known condition" that would cause a form's BeforeUpdate event to actually trigger, but still err (and not because of a mistake in the BeforeUpdate event code) before completely updating?

Put another way: Once the BeforeUpdate event fires, and if there was no code inside the event (just the stub), theoretically could it ever fail in between the time it first fires, and the time it ends? In other words, all else being equal, do you not believe that BeforeUpdate firing is an indication that the update is going to succeed?

Regardless of the answer, I stand by my evaluation that neither method suggested was perfectly guaranteed to be accurate in absolute terms. A table driven approach might have.
Your view on my suggestion is roughly how I feel about your oft-suggested DoCmd.RunCommand, in cases that are extremely context/focus-sensitive. I'd say it's much easier to damage one's data by using DoCmd.RunCommand (and have the Focus on the wrong form/subform), compared to my suggestion in this post.
To each his own - people are going to have different takes on the relative risks of all mentioned items.

 

[Isaac]

If Me.Dirty = False Then Me.Dirty = False End If

I think you meant to type true in first line.

 

[KACJR]

The "Dirty = False" statements should ALWAYS be encased in an If statement. You don't want to force a record to save unless it was changed.

If Me.Dirty = False Then
   Me.Dirty = False
End If

The Form's BeforeUpdate event should only ever run if the record was dirtied. If it is running every time you scroll to a new record, something in your code is dirtying the record and it shouldn't be.

Sorry. All of the Dirty commands were part of an If...Then as you noted. In any event, I commented them all out until I'm certain that everything is functioning as it should. From the looks of it, the Dirty commands were overkill.