oolean variable being changed, but not by code

[JimO]

The problem is that a global boolean variable is being changed from true to
false, sometimes. We saw it happen three out of 11 tests. It is not being
reset by code. How can this happen?

The biggest fears is that if the value of one variable can be changed by the
"system" then any variable can be changed by the system.


Facts.
The database references the boolean variable only five times and never in
either code library.
Once to declare: Public gbooUseCDO as Boolean
Once when intializing and the initialization routine is executed only
once per run.
If conditions = true
gbooUseCDO = true <====== Set to true here
else
gbooUseCDO = false
end if

Twice at various points.
if gbooUseCDO then <====== three out of ten times the
value was False at this point.
code
else
code
endif

Additional information.
The database was originally coded in Access 2000, ported to 2002, and now
2003. "Track name AutoCorrect Info" was enabled on until recently, although
this variable was added after disabling the option.

References
Visual Basic for Applications
Microsoft Access 11.0 Object Library
OLE Automation
Microsoft ActiveX Data Objects 2.7 Library
Microsoft Excel 11.0 Object Library
and the two .mda code librarys

System configuration
MS Windows Server 2003 Standard Edition SP 1
Access 2003 SP2 (MS Office Professional Edition)
The server is being accessed by remote desktop via a VPN connection .

 

[Klatuu]

Where is the variable declared, ie, what type of module?
To be a Global variable, it must be in a standard module.

 

[JimO]

Thanks for responding. It was declared in a standard module. Had it been
declared in, for say a form module, the code would never execute because of
the Option Explicit declaration. Of course, I didnt mention that
declaration.

 

[Klatuu]

Option Explicit only affects the module it is in, regardless of the module
type.

Since I don't use Global variables, I can't be sure, but I think that even
if your form module has Option Explicit and if references a variable declared
in a standard module as Public, you would be able address it without a
problem.

A Public varialbe declared in a Form module is visible only within the Form.

It is also possible (but I haven't tested it) that if you declare a public
variable in a standard module and then reference a variable in a form module
that is not Explicit, it will create a local variable with the same name.

I never declare a varialbe any higher than at a form level. This may be a
bit over cautious, but in some other environments I have worked, it can be a
problem.

My solution to the problem is to use a function in a standard module with a
static variable.

 

[John Spencer]

Do you have any unhandled errors? ALL VBA variables can get reset when an
error occurs if you don't have code handling the error.

For this type of thing, I generally use a hidden form with a control on it.
I then reference the form's control to get the value. Error's don't resent
the control's values. Another possibility it to use a custom database
property.

Another solution is to change the boolean variable to an integer and set the
value to something other than zero and then test for that value. If the
value is zero (which it will be if something causes a reset), then you can
rerun the initialization routine or do something else to handle the problem.

 

[JimO]

Sort of. There are various places where a "On Error Resume Next" was in
force rather than "On Error GoTo ErrorRoutine" so they are unhandled. Most
of these were dealt with this morning but one case was where a check was
being made to see if an object existed. In this case it was looking for a
table. The code sets a value to true if the object exists but uses an on
error goto if it does not. I will change this code to search the catalog
for a match and if depending on a match or not set the return code.

Of course, the latter error was being "handled" but since it is the only
code that fails when Break on All Errors is set then I will fix it.

Now, the program had been run many times prior to the observed error. A
false condition opens a message box so it would have been noticed. The
condition happened three times in a row and did not fail during the next 7
tests.... nor has it failed since.

Let me ask this. What happens in this case?
Sub Sub1
On error goto ErrorRoutine
Call Sub2
PERFECT code along with exit and error routines.
end sub

Sub Sub2
bad code here, with no error routine or error handler
PERFECT code from here on... that will not be executed because the next
line executed will be the first line in the ErrorRoutine of Sub1.
End Sub

Would that be considered unhandled? Is On Error Rresume Next considered
unhandled?

Thanks for your time.