Variables being reset after conversion from 97 to 2000

[Dick Russ]

After converting from Access 97 to 2000, most functions worked correctly.
However, when I enter a report from within the VBA code, the report displays
properly but then resets virtually all variables (integers are 0, strings are
"", etc) when the report closes. Public and private variables in all open
forms and modules are affected.
Has anyone experienced this or have any clues about how to prevent it.

 

[Chris Mills]

I can only say that conversions from A97 to A2000 were always problematic.
1) A97 could have "corruptions" which did not necessarily prevent A97 from
working.
2) A2000 was the second flakiest version (behind A95)

A conversion (in my experience) is unlikely to succeed without error unless
you do the following.
1) A complete Decompile/Compile/Repair/Compact in A97. Some may argue about
the necessary steps, just that's what I did.
2) Same in A2000 after conversion. Whether this is necessary, neither does it
any harm.
3) Check your new references at some stage (Code module, Tools, References)

If you have "inadvertent resets", it may be messed up code, but it seems to me
most likely a messed up conversion. I do not mean "you" messed it up!

All evidence (newsgroup evidence that is) suggests A2k2 was more stable.
Though I still have A2000 apps (and A97 apps), I would not even think of
converting to A2000 nowadays. The evidence says A2002 (itself obsolete) was
better. I have no opinion on A2003, though anecdotes say it is at least better
than A2000. I'm talking stability, not functionality, such as you discuss.

//
There were a number of code changes required A97...A2000, which, because it
was the same VBA and involved "bugs" not functionality, I could just retro to
the A97 version of my dual-app. I've now forgotten what they all were, anyway
they may have been my own mistakes. If my experience is anything to go by, A97
to A2000 is not easy as a first experience. In particular, conversions just
hang if there is any "corruption".
//
//
You are probably trying to analyse a "corruption". "Corruptions" are for the
large part, not analysable, or best analysed with a big heavy hammer (do it
again).
//
Chris

 

[Van T. Dinh]

One of the major problems with Public Variables is that they are reset to
their default values (as you wrote) if any untrapped error occurs in your
code execution.

It sounds to me that this is the problem you have. Generally, if you use
Public Variables, you need to use error-trapping in every bit of VBA code
you have in your database.

Most programmers avoid using Public Variables. There are a number of
work-arounds and I often use TextBoxes on a hidden Form.

 

[Chris Mills]

Most programmers avoid using Public Variables.

I use 'em say a global public variable for "Company Name" to appear on
EVERYTHING, Sure i's taken from some config table somewhere, just seemed
faster/simpler/"CONFIG" as a parralel in every source query?

I am looking for education, not having you on.

I assume "all errors trapped" in a professional application, so that's a very
good point. But doesn't ALL VBA need error trapping (eg in runtime), so what's
this business about "most programmers avoiding public variables?" It's just
the first I've heard that statement, I think.

Best regards
Chris

 

[Van T. Dinh]

I didn't want to mention that the bigger the scope, the more potential to
change the value accidentally, also.

Sure, if you are careful, there is no problem using Public Variables but
then storing values on a hidden Form doesn't take much time to code. In
fact, I use hidden Form to temporarily store values and I use functions to
retrieve and _validate_ the values before using them. This way, I don't
accidentally use incorrect values, e.g. resset.

In discussions with Access (and VB) people I work with, they all try to
minimize the use of Public Variables but then, I suppose, your experience
may be different and equally valid.

 

[Dick Russ]

Thanks for the help and the advice. I was doing a 'Save As' over top of an
existing report. I had the warnings turned off so that the user would not be
annoyed by an expected warning. I got around the problem in 2000 by deleting
the old copy of the report before saving the new one.

 

[Guest]

I use 'em say a global public variable for "Company Name" to appear on

Public values should be in public variables: private values
should be in private variables. In general, if it CAN be a
private variable, it SHOULD be a private variable.

I use a database property for application name. Database
properties, like public form properties, are, of course, a
kind of public variable.

I wouldn't normally use a VBA public variable for something
like that: I would use an Access public variable (form or
database property), but that is because VBA public variables
are (a) not persistent: you need to reset them every time
the application ends, and (b) aren't visible to Access: you
need a function anyway if you want to use the value in
a query, macro, control property etc.

(david)