Access 2003 resets form variables during debugging while the form is open

[Yarik]

Hello,

I am using MS Access 2003. (FWIW, this is about an ADP project, not
MDB.)

A form has a variable that is initialized (by some function call) in
Form_Load() and then stays unchanged for the form's entire lifetime.
(In a language more advanced than VBA, it would be a constant, not a
variable; unfortunately, in VBA I cannot initialize a constant by non-
constant expression). Specifically, in my case it looks like this:

Private sTempFileName as String
...
Private Sub Form_Load()
...
sTempFileName = GenerateTempFileName(...)
...
End Sub

Private Sub Form_Unload()
...
' Use sTempFileName to delete the file
...
End Sub

Private Sub SomeEventHandler(...)
...
' Use sTempFileName to read from (or write to) the file.
...
End Sub


At run-time, everything works just fine.

However, when I am debugging the application, the following problem
occurs: while the application is running and the form is open in "form
mode" (i.e. not in design mode), certain "on-the-fly" changes of the
application's code cause Access to "reset" the abovementioned variable
- silently! The variable becomes blank/empty, just like it was before
initialization in Form_Load, and obviously the form, relying on
variable's being initialized, becomes inoperational.

Interestingly enough, I don't remember a case when a change to the
form's own code would ever cause this problem. The simplest way I
found to reproduce this problem is to change some class module used by
the form.

My brief experiments demonstrated that this happens with all form
variables, regardless of their types - they all get silently
"reset"...

I do not remember such behavior in MS Access 2000 ...

So my question is:

Is this "problem" a feature or a bug in Access 2003?

Thank you,
Yarik.

 

[Guest]

I have read before that you should never edit code in break mode or while the
form is otherwise running. Access can apparently get confused between the
versions of code at compile time.

Despite that, even if you are not in break mode and you edit code, sometimes
global variables will be reset.

You could use a function to return the value of the variable. In the
function, check the variable and if it is not initialised you can reset it
before returning it. If it is truly a constant, why not just use a function
to return the value and not use a variable at all? I tend to do this for all
my global level constants...

Steve

 

[Larry Linson]

What you have written seems to me to describe that it is "working as
designed" and in the same way that Access has worked in all previous
versions. That is, when you make certain changes to the code, it is the same
as doing a RUN RESET -- the code must be recompiled, either explicitly or
implicitly and variables are reinitialized; or when an unhandled error*
occurs, the value of variables is lost (and the latter occurs even at
runtime, for unhandled errors).

* when I debug, I generally set "break on all errors" so
I am taken right to the offending line, thus by definition,
all those errors are "unhandled" (not handled by an
On Error GoTo error procedure).

To maintain a value, (1) when the variable goes out of scope or in case of
unhandled error, you can save the value in a Control on a hidden form or use
a property of an instance of a class module to hold it, or (2) across
execution instances, write it to a table or an external file or create set,
and save a Property of the database.

In the code you show, the sTempFileName variable appears to be a Form-level
variable, so will be lost once you are executing outside the Form's module.

In the last 50 years, I've worked in so many programming languages that the
list, in 12-point type, would be longer than the average programmer's
elbow-to-wrist measurement, and in not a single one of those could a
constant be set from a variable -- by definition, in all the programming
languages I've used, a constant was a value that was set at compile or
assemble time. And, I haven't heard that was redefined in any "advanced"
languages - not plain and simple, not complex, not machine-oriented, not
problem-oriented, not object-oriented. So I'm wondering what "advanced"
language did you have in mind that allows setting constants from variables,
or arguments, or parameters?

Of course, unless you're jumping through some hoops, you don't have local
tables in an ADP, but that's only one option. Otherwise, I believe the
behavior under consideration is the same in ADP and MDB. You are aware, I'm
sure, that the Access team at Microsoft now recommends MDB <-> ODBC <->
Server DB as the method of choice over ADP <-> ADODB <-> SQL Server, in
contrast to the marketing push of releases past for ADP/ADO. But, ADP is
still fully-supported, even in Access 2007, not deprecated (as Data Access
Pages have been in Access 2007).

Larry Linson
Microsoft Access MVP