Global variables being unset somehow!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Are there any circumstances that can cause global variables to be unset? I
know this can happen after an error, if processing continues.
I have an obscure bug that seems to be being caused by global variables not
being set. They are always set on initialization so this means they must be
being unset somehow. As far as I know, no error has occured.
After the global variable has been unset, I am getting error trap screens
that say the error number is zero.
 
Have you added a breakpoint in the procedure that runs your
"initialization"? If you do this, you'll be able to step through the code,
having Access execute it line by line, until it "breaks". You can also use
this approach to inspect the values to see when they are set/unset.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
I'd love to be able to do this but I cannot reliably reproduce the problem.
I don't think the initialization code is a problem, it runs once at the
start of processing and then never again. Something in my code seems to be
triggering the unset of the globals.
 
Were this my situation, I'd next "undo" global error handling and have each
procedure able to break on error. That way, when the call the global
variable came unset, the next procedure that used it would fail. This would
get me closer...

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
You probably do have some error, and you not seeing a message.


Why not always run the application as a mde, and then un-handled errors do
NOT re-set variables.

So, you can have errors occur..but variables will not get re-set until you
close the appcation.

So, just always use a mde for your end users.

Using a mde means that you likely have to split your database, since once
you convert a mdb to mde, you can't make changes to code...

I talk about using mde here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
 
The only time I see that is if an unhandled error occurs in the code. One
thing you can do (and it is tedious) is to check the global and see if it
has reset to the default value for the variable type.

Another solution is to "store" the values in controls on an always-open
invisible form and reference the controls on the form instead of the global
variable

--
John Spencer
Access MVP 2002-2005, 2007
Center for Health Program Development and Management
University of Maryland Baltimore County
..
 
The only time I see that is if an unhandled error occurs in the code. One
thing you can do (and it is tedious) is to check the global and see if it
has reset to the default value for the variable type.

Another solution is to "store" the values in controls on an always-open
invisible form and reference the controls on the form instead of the global
variable

Another more obscure case is when you try to trap for closing Access
with the X button. This technique involves canceling the Unload event
for a form that is always open and hidden. Access will not only leave
that form open, but will also cancel the whole shutdown of Access. A
handy technique. But during the aborted shutdown process, it will
lose all global values.

This is why it's a good practice to avoid long-lived global variables,
unless you can reload them on the fly any time they are null.

For example, you might have configuration data in tables that you want
to use throughout your application very quickly. Use a function to
return the global value if it is loaded, otherwise reload it and
return it. This essentially gives you a "self-healing global".

Another technique is to switch all your globals to values on a hidden
form, which persist when globals fail.

And new for Access 2007, TempVars can be used instead of globals, and
they persist also.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
Another technique is to define these "global variables" as functions rather
than variables. I use this all the time for just this reason (it also allows
me to use the values in stored queries, which global variables do not). You
can change the return type of the function to the appropriate type, if
needed, but I alway make the parameter a variant, so I can set it to Null if
not provided.

Public Function fnSomeVar(Optional SomeValue as Variant = Null) as variant

Static myVar as Variant

if Not Isnull(SomeValue) then myVar = SomeValue
fnSomeVar = myVar

end function

Had a discussion "Using collection to store variable values" about this with
Marshall Barton in the FormsCoding newsgroup just last week.

HTH
Dale
 
Back
Top