Global variables lose values

[Shep]

I have found that if I navigate to the end of a recordset, all global variables either are emptied, or revert to an opposite value (such as in the case of boolean variables).
Can anyone explain why this occurs and how I might prevent it?
Is it simply because a runtime error occurred? (2105)

Actually, it is occurring when I attempt to navigate (in code) past the end of the recordset. I am still working on this particular module and have not yet polished it up or added error handling code.

Many thanks,
Shep

 

[Pat Hartman]

I don't know what causes the problem. Not all application errors seem to reset the variables. I haven't had any problems with "production" systems since they don't normally fail. The value loss is really only a problem when you are actively developing and experiencing abends. I got so tired of this particular problem when I was testing a big database a few years ago that I built an unbound form to hold the variables. The form opens hidden when the application starts and I use it to hold any global variable in unbound text boxes. Now I just use the hidden form technique for all databases. The hidden form has an upside in that while you're testing, you can leave it visible and change the variables by hand rather than having to make various pieces of your code run to set them.

 

[The_Doc_Man]

I think at least part of the problem might be re-instantiation of the variables. Most ordinary VBA variables are instantiated in a way that makes cleanup an automatic action when the modules in question go away (become de-referenced). In practise, this usually means that they reside in the application's stack area. Collapse the stack, you collapse the variables too. At least, that is how I read the symptoms you describe.

When you have a signalled error and it is not handled in your immediate VBA routine, a handler from a higher level has to handle the error. I'm not going to guess what happens to anything in that higher level - or anything that depends on that level. But there is at least the outside chance that this would collapse the stack to handle the error.

The term "Global" does not address a variable's longevity - only its visibility. I believe "Static" defines the longevity of a variable. You also don't say whether the problem is in a class module or a general module, but that detail also affects variable longevity. I suspect that if you defined a general module with your variables listed in the definitions area as both global AND static, you might overcome this problem.

I will freely admit I could be terribly wrong - but adding keyword "Static" in your global definitions is an easy experiment, so I won't be wasting much of your time if I'm wrong.

 

[Shep]

That's ok, Doc_Man, I think the distinction would only be truly important were I to spend my time testing variable types vs longevity, but I don't think I feel like doing it today.
After watching this for a while, I feel that yes; the memory space used to store the variables is dumped when certain runtime errors are issued. The details are not too important, since these errors (hopefully) will not occur when the code is put to use in it's final form. By the way, the globals are declared in a general module but the error is generated in a class module. It's just an end of recordset runtime.

Interesting, Pat. I do something similar when developing. I create a form with textboxes and command buttons so that I can set the variables whenever I wish. I had not considered leaving the form hidden in place for later use. Good idea.

My thanks to both of you.
(Now if I could only find a way to develop an application without pop-up and modal forms acting the way are supposed to and getting in the way!)

Shep