Constantly repeating MsgBox (1 Viewer)

smig

Registered User.
Local time
Today, 05:54
Joined
Nov 25, 2009
Messages
2,208
I have a function that I put some MsgBox in it trying to trap an "Out of stack space" error
Code:
Public Function fnGetDbVersion(strFileName, strFilePassword) As String

On Error GoTo errHere


fnGetDbVersion = 0

MsgBox "_fnGetDbVersion - 1"

Set DataDB = OpenDatabase(strFileName, False, False, "MS Access; PWD=" & strFilePassword & "")

MsgBox "_fnGetDbVersion - 2"

strSQL = "SELECT * " & _
    "FROM [dbVersions] " & _
    "ORDER BY [dbVersion] DESC "

MsgBox "_fnGetDbVersion - 3"

Set rs = DataDB.OpenRecordset(strSQL)

MsgBox "_fnGetDbVersion - 4"

With rs
    If .RecordCount > 0 Then
        .MoveFirst
        fnGetDbVersion = .Fields("dbVersion")
        .Close
    Else
        fnGetDbVersion = 0
    End If
End With

MsgBox "_fnGetDbVersion - 5"


ExitHere:
    Set rs = Nothing
    Set DataDB = Nothing
    Exit Function

errHere:
    fnGetDbVersion = 0
    Call ErrorHandling("mdl_Mithazim_GetFunctions", "fnGetDbVersion", Err, Err.Description)
    Call pbCleanAfterError
    Resume ExitHere

End Function

Now it will constantly show the "_fnGetDbVersion - 1" MsgBox :(
what can cause this situation

there is sure no loop in the code. nor in the code calling this function


this is the code calling the function
Code:
sngDataMDBVersion = fnGetDbVersion(pbDataPath & "\" & pbDataFileName, pbDataFilePass)

*** EDIT ***
After this MsgBox (I click OK) it show it again.... and again.... and again .... :(
The code is get stuck showing the same MsgBox (Won't show _2_
 
Last edited:

plog

Banishment Pending
Local time
Yesterday, 21:54
Joined
May 11, 2011
Messages
10,916
What's the code calling this function?
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 19:54
Joined
Oct 29, 2018
Messages
18,972
By any chance are you using this function in a query?
 

smig

Registered User.
Local time
Today, 05:54
Joined
Nov 25, 2009
Messages
2,208
By any chance are you using this function in a query?
no. no query

sngDataMDBVersion = fnGetDbVersion(pbDataPath & "\" & pbDataFileName, pbDataFilePass)
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 22:54
Joined
Feb 19, 2002
Messages
36,296
The code always displays that error. Are you missing an If statement in the function?
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 03:54
Joined
Sep 12, 2006
Messages
14,835
I presume after your message box, you are resuming to a piece of code that produces the same error, and the only way out is to use Task manager to kill access. Thinking about, if you are out of stack space you won't be able to call any sub, as the stack is full. Are you running some recursion, or running a long loop that is programmed wrongly, and is unintentionally filling the stack?

you probably should

resume pbCleanAfterError rather than
Call pbCleanAfterError

and have
pbCleanAfterError run the exit commands.

You don't want to run anything that might error within an error handler.

Put a breakpoint in the error handler, and follow the code execution, and you will most likely see this happening.
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 22:54
Joined
Feb 19, 2002
Messages
36,296
Now it will constantly show the "_fnGetDbVersion - 1" MsgBox
Look again at the code procedure. This message will always be displayed since it is not conditional.
 

plog

Banishment Pending
Local time
Yesterday, 21:54
Joined
May 11, 2011
Messages
10,916
Look again at the code procedure. This message will always be displayed since it is not conditional.

Its supposed to, as is every msgbox; They are trying to find the failure point.

smig--not just the line of code but the entire calling function.
 

plog

Banishment Pending
Local time
Yesterday, 21:54
Joined
May 11, 2011
Messages
10,916
Is OpenDatabase() a custom function? Have you fallen into unintended recursion?
 

smig

Registered User.
Local time
Today, 05:54
Joined
Nov 25, 2009
Messages
2,208
Let me be more clear

After this MsgBox (I click OK) it show it again.... and again.... and again .... :(
The code is get stuck showing the same MsgBox (Won't show _2_
 

smig

Registered User.
Local time
Today, 05:54
Joined
Nov 25, 2009
Messages
2,208
I presume after your message box, you are resuming to a piece of code that produces the same error, and the only way out is to use Task manager to kill access. Thinking about, if you are out of stack space you won't be able to call any sub, as the stack is full. Are you running some recursion, or running a long loop that is programmed wrongly, and is unintentionally filling the stack?

you probably should

resume pbCleanAfterError rather than
Call pbCleanAfterError

and have
pbCleanAfterError run the exit commands.

You don't want to run anything that might error within an error handler.

Put a breakpoint in the error handler, and follow the code execution, and you will most likely see this happening.
After this MsgBox (I click OK) it show it again.... and again.... and again .... :(
The code is get stuck showing the same MsgBox (Won't show _2_

I guess this is what filling up the stack space
but why ???
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 19:54
Joined
Oct 29, 2018
Messages
18,972
After this MsgBox (I click OK) it show it again.... and again.... and again .... :(
The code is get stuck showing the same MsgBox (Won't show _2_

I guess this is what filling up the stack space
but why ???
Have you tried stepping through the code? Just curious...
 

MajP

You've got your good things, and you've got mine.
Local time
Yesterday, 22:54
Joined
May 21, 2018
Messages
6,369
I cannot see anything in the code that would cause that behavior. I would run it with the "on error" commented out and see if this breaks anywhere.
My first thought was
fnGetDbVersion is defined as a string and you do
fnGetDbVersion = 0
Most of the time access will cast 0 to "0" so it should not error. However, I tried this an it does cast 0 to "0" without an issue.

This may be a long shot, but easy enough to try. You may want to decompile and recompile. Decompiling removes old code that did not get compiled correctly. In very rare cases I have seen that as the explanation to why my code is doing something that the visible code is not instructing. Normally corruption stops code from running at all, but it can cause strange behavior too.

Imagine at one time you accidently wrote this when testing something
MsgBox "_fnGetDbVersion - 1"
fnGetDbVersion "-", "1"

Now you accidently created a recursive call. It errors running out of stackspace. The symptoms looks as if that is happening, even though there is nothing in your code as far as I can tell. Even though you delete that bogus line it is now in the compiled "corrupted" code. It will run as if that line of code really exists.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:54
Joined
Feb 28, 2001
Messages
22,792
First, can you set a breakpoint in there so that you can execute a single-step? If you can, you need to use the menu bar to view the call stack and see how deep it is, because if there is a recursion that is chewing up your stack space, it will show there. Also, is it possible that somewhere "above" this routine (logically speaking), some called routine that leads to this function has a lot of dimensioned (DIM'd) items?

Second, if you CAN set a breakpoint, single-step to see what line fails to execute. I'm going to guess the OpenDatabase is the thing that fails because such a thing will almost certainly eat stack space like there is no tomorrow.

Third, the mechanism for this is unclear, but I know that error traps in general (of which "Out of Stack Space" is clearly a trap) have to be able to toss some emergency context onto the stack. If they cannot do so, the question becomes "What was done with/to the stack?" The last thing on the stack is the entry to the function, which might (emphasis MIGHT) cause you to repeat that code entry point. I have seen trap loops in some systems and there is no reason to exempt Windows or Access from generating such a loop.

Finally, though you can call a "common error routine" to handle the logging and annunciation of the error, that "clean after error" routine is something that should go anywhere BUT an error trap routine. You see, trap context is NOT like function or subroutine context. It ties up your system in a complex state that is distinct from ordinary event-level code. The more you do inside trap context, the longer your system is blocked from doing anything else, because traps are queued up at a higher priority than events. (Events cannot interrupt other events, but a trap can interrupt an event.) So while that trap code is running, nothing else in your session IS running, not even Access itself. If you were to move that "clean after error" code elsewhere OUTSIDE of the trap handler, you will put less strain on your system by decreasing the amount of time spent in trap context. Does that "pbClean..." routine do anything bad if there WAS no error? If not, take it out of the trap code and put it just after the ExitHere: label.
 

smig

Registered User.
Local time
Today, 05:54
Joined
Nov 25, 2009
Messages
2,208
Tישמ
First, can you set a breakpoint in there so that you can execute a single-step? If you can, you need to use the menu bar to view the call stack and see how deep it is, because if there is a recursion that is chewing up your stack space, it will show there. Also, is it possible that somewhere "above" this routine (logically speaking), some called routine that leads to this function has a lot of dimensioned (DIM'd) items?

Second, if you CAN set a breakpoint, single-step to see what line fails to execute. I'm going to guess the OpenDatabase is the thing that fails because such a thing will almost certainly eat stack space like there is no tomorrow.

Third, the mechanism for this is unclear, but I know that error traps in general (of which "Out of Stack Space" is clearly a trap) have to be able to toss some emergency context onto the stack. If they cannot do so, the question becomes "What was done with/to the stack?" The last thing on the stack is the entry to the function, which might (emphasis MIGHT) cause you to repeat that code entry point. I have seen trap loops in some systems and there is no reason to exempt Windows or Access from generating such a loop.

Finally, though you can call a "common error routine" to handle the logging and annunciation of the error, that "clean after error" routine is something that should go anywhere BUT an error trap routine. You see, trap context is NOT like function or subroutine context. It ties up your system in a complex state that is distinct from ordinary event-level code. The more you do inside trap context, the longer your system is blocked from doing anything else, because traps are queued up at a higher priority than events. (Events cannot interrupt other events, but a trap can interrupt an event.) So while that trap code is running, nothing else in your session IS running, not even Access itself. If you were to move that "clean after error" code elsewhere OUTSIDE of the trap handler, you will put less strain on your system by decreasing the amount of time spent in trap context. Does that "pbClean..." routine do anything bad if there WAS no error? If not, take it out of the trap code and put it just after the ExitHere: label.
The "Clear after error" can't go another place
it is to reread public vars that where lost by the error

the problem is the code is getting stuck and constantly (On Office 365 machines, not mine) on this msgBox
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 03:54
Joined
Sep 12, 2006
Messages
14,835
it's not stuck on the msgbox. It's closing the msgbox, but immediately getting another rte.

if the stack is full then virtually anything you do will cause a rte. It will then go to the last active error handler. If it's not exiting this sub, you will keep seeing this error message, but it's nothing to do with what you thought would trigger this error message. The real cause of it is somewhere else.

You need to put an break in this error handler, and then step through, and you will see the next call that causes an error (a rte - run time error) . Any instruction that pushes items on the stack will cause an error. That will include many instructions that wouldn't ever error normally and which you won't be checking for. It's similar to the hard disk getting full. I bet no one ever builds in code to check for that either nowadays.

So the thing you need to trace is why the stack is getting full, and the only real likely cause is an accidental, or intentional recursion that isn't terminating., although possibly a process examining a lot of items could conceivably fill the stack, depending on what you are doing.

Recursion is a process calling itself, and each time, it pushes the call information to the stack. If you never stop the recursion, the stack just fills up and eventually crashes. (eg as @MajP illustrated)

eg If you write a chess programme that examines future moves from the current position by recursion, pushing the new position on to the stack to be examined, then the programme will examine positions deeper and deeper until it runs out of space. Therefore you have to write the programme carefully to control how deeply you can examine the position, and probably find an alternative to the recursion, or limit the depth of the search. I can see how to do it with recursion, but not without.
 
Last edited:

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 10:54
Joined
May 7, 2009
Messages
16,394
you should also consider looking at what these two routines are actually doing:

Call ErrorHandling("mdl_Mithazim_GetFunctions", "fnGetDbVersion", Err, Err.Description)
Call pbCleanAfterError
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:54
Joined
Feb 28, 2001
Messages
22,792
The "Clear after error" can't go another place
it is to reread public vars that where lost by the error

Unless you do the RESET that is associated with an improperly managed error, Public variables do not get lost except if YOUR code damages them.

If you are saying that you are trying to reset copies of local variables to some initial condition, I have to break the bad news to you. A "stack space" run-time error isn't really recoverable anyway. At that point, crucial program infrastructure information has already been lost.
 

Users who are viewing this thread

Top Bottom