Opposite of Current Event (1 Viewer)

[Kayleigh]

Hi, I have quick question:
What is the opposite of the current event?
I want to be able to easily return to the last record in datasheet view so I will have a button on the form which will update every time the current is triggered. So how do I store the record ID before it moves to the new record?

 

[theDBguy]

Don't think there is one. If you simply want to go through the records one at a time, you can use the GoToRecord method.

 

[Kayleigh]

I'll be using different filters so use a variable to store record ID. But was wondering if there was better option.

 

[MarkK]

You could keep track of the previous ID like this...

private currID as long
private prevID as long


Sub Form_Current()
   prevID = currID
   currID = Me.RowID
End Sub

 

[Pat Hartman]

Use the built in navigation buttons. That's what they are there for.

 

[MajP]

You would still use the current event. If the store the ID when you enter a record or store it before you leave it makes no difference.

 

[Pat Hartman]

If you store the ID, you may also need to remove the filter first in case your current filter eliminates the previous record.

 

[Kayleigh]

Thanks @MarkK - really helpful!
I also store the filter in another variable and then do a comparison to check not clashing...

 

[The_Doc_Man]

If your goal is to store the ID of the previous record, the Form_AfterUpdate event applicable to that record is a good candidate. If there was an autonumber ID involved, it has been updated and committed at the moment of the update, but navigation hasn't occurred yet. After that event... where you are next depends on what you are doing. Oh, there WILL be a current event - but for which record? That is the "depends" part.

In the technical sense there is no "opposite" event to Form_Current. There are chronologically earlier and chronologically later events. This link might help.

Order of events for database objects - Microsoft Support

support.microsoft.com

Remember that it DOES NOT MATTER whether you have code for a given event. Access ALWAYS recognizes events. In fact, it is Access code that just calls your code if you happened to have an event routine defined for the specific event.

 

[Pat Hartman]

Putting the code in the AfterUpdate event is probably necessary if records can be added. But, when records are not added, the code needs to go in the Current event. The code could be more sophisticated. In the Current event, you could check for Me.NewRecord and store a null. Then in the AfterUpdate event, the code could replace the stored value with the actual ID. No "If" is necessary since it doesn't hurt to replace 123 with 123 if the PK already exists.