The way that error handling works:
First, you are ALWAYS in subroutine/function context in any VBA code you write. MSACCESS.EXE is the MAIN program. Everything you write is a subroutine or function of some sort. Subroutine/function context is established when you do something to call any Function/Sub entry point. At the moment you enter that routine (be it an On some-event routine, a function invocation, or a sub invocation), the system creates a Call Frame (an area to store context) on the Call Stack. The On Error statement depends on / interacts with one of the slots in the current Call Frame. When you set On Error GoTo xxx or On Error GoTo 0 or On Error Resume xxxx or On Error Resume Next, that setting is written into the Call Frame's Error Handler Entry Point slot. (Just like a Form Load looks for and calls an entry point called Form_Load.)
The Error Handler entry point stays that way until one of two things occur: (1) You explicitly perform ANOTHER On Error statement to overwrite the previous one, or (2) you Exit Sub / End Sub from that routine - which destroys the Call Frame that held the Error Routine entry point. Some people MIGHT think that there is a third option (call another routine, which establishes a new Call Frame and thus allows for a new target for the On Error statement.) However, when THAT routine exits, the previously established Error Routine is back in play because its Call Frame was merely dormant on the call stack.
That Error Routine Entry Point declaration can be re-used as often as you can legally devise your logic flow to re-enable it. The ONLY "legal" way to re-enable the 3rd layer's Error Handler entry from the 3rd layer is to execute a RESUME to a label also in the 3rd layer. That RESUME dismisses the error context without exiting the subroutine. Remembe, an Exit Sub / End Sub dismisses error context but also dismisses the call frame.
There is one more situation that applies to an Error Routine Entry Point. An Error Routine CANNOT interrupt another active Error Routine. Therefore if you have three call layers active and take an error in the 3rd layer, that layer's error routine gets called. BUT if there is an error during the 3rd layer's Error Routine, it cannot interrupt itself - so the 2nd error bounces up to the 2nd layer's error routine, which presumably isn't active at the moment.
IF the 2nd layer doesn't have a declared error handler then that 2nd error bounces up to the 1st layer. Either it gets handled there or it bounces up to the Access "Last Chance" Error Routine - which gives you the dreaded message box declaring the error and giving you the option to Reset or Debug. And at that point, all three subs are now "unwound" from the stack. A stack Unwind implies total loss of context including cancellation of the Error Routine Entry Point declaration.
So back to the original question: Taking another error in the same routine would ATTEMPT to use the previously declared error handler entry point UNLESS you were actively executing in that error routine when the error happened. Exiting from a routine would cancel that routine's previous declaration and revert to whatever was the previous handler. And if that was the Access handler, you likely have an application crash or exit due to an unhandled error.
