Constantly repeating MsgBox

[smig]

I have a function that I put some MsgBox in it trying to trap an "Out of stack space" error

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

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_

 

[plog]

What's the code calling this function?

 

[theDBguy]

By any chance are you using this function in a query?

 

[smig]

What's the code calling this function?

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

 

[smig]

By any chance are you using this function in a query?

no. no query

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

 

[Pat Hartman]

The code always displays that error. Are you missing an If statement in the function?

 

[gemma-the-husky]

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.

 

[Pat Hartman]

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]

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]

Is OpenDatabase() a custom function? Have you fallen into unintended recursion?

 

[Pat Hartman]

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

 

[smig]

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]

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]

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]

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.

Access Keeps Crashing when I go click Debug

Hi, I have just been working on Crosstab queries and reports with parameters and have got it all working (or so I thought). I am now getting an error on the Querydef function where I am setting up the parameters of the query in VBA before calling the report. I have no idea why this isn't now...

www.access-programmers.co.uk

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]

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]

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]

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.

 

[arnelgp]

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]

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.