Are TempVars Good or Evil?

  • Thread starter Thread starter Kari
  • Start date Start date
K

Kari

Not so long ago when I was just learning Access, I found some code somewhere
that helped me open a report with criteria set on a form. The code used a
Temporary Variable to collect the info from the form (via a textbox) and
filter the query.

Now I'm revisiting the report, trying to add some additional functinality
and I'm wondering about that Temp. Variable. I've not seen TempVars in any
form suggested as solutions to anything. When I search on them I find almost
nothing on this discussion board (one poster wanted to know how to track them
and one tried to use them with no success). None of the books I've seen
mention them and help is (as is common) not very helpful (there just isn't
much there).

My question for you experts out there is: are Temp Vars good or evil? Are
they a good tool used in the right circumstances or will they come back to
haunt you and make you wish you had never taken up the Programmers Keyboard?
If they're useful, what circumstances call for them? What are the pitfalls
to watch out for? Are Global Variables a better idea?

I'd like to get the opinions of those who've used Access for a long time
(not just beginning to get comfortable with it, like me) to figure out if I
should retool my existing report, and whether I should use them in future
applications.

I appreciate your time and opinions.

Kari
 
All variables are temporary as they don't outlive the object which creates
them. (With the exception of static variable defined in a procedure).

With Access, you can see three main scopes:

Access scope, the whole application, and "Global variables" are created
in that scope, in the declaration section of a standard module. The global
variables are visible (accessible) everywhere (unless you succeed to declare
a local variable with the same name which will hide the global variable).
They can be seen as Let/Get/Set properties you add to Access itself. They
may reset themselves if you 'stop' a debugging session, in some cases. Since
there is only one instance of Access seen by your code, each global variable
is UNIQUE, for the whole application.

The Class-Object scope are variables which are created in the class
declaration. They are also called attributes, or fields. If they are
public, they are like properties for that objects of that class (with a
Set/Let/Get accessibility). Those variables which are private are only
visible from code contains within that class definition. These variables are
maintained "by object". As example, if the class car defines an attribute
Color, and if you have two cars objects, then, each of these objects can
have a different Color. If Color was implementd using a global variable
rather than a class attribute, since there would be only one such variable,
all your cars, all you cats, all your dogs will have the SAME color.

The Procedure declared variables are created within a
subroutine/function make the third scope. They are the most common ones if
you don't use class much. Those variables live only for the duration of the
function evaluation. The "static" variables defined in a procedure are an
exception since they outlive that duration.The local variables are only
visible (accessible) from within the procedure which declare them and tend
to be the ones which are the most 'temporary'... There is no much problem
using them, but it is nice to avoid name collision with global variable.
That is why you should limit the number of global variable and when you use
them, try to use particular name for them so you are unlikely to use the
same name as procedure level variable.


============= in a standard module ====
Option Compare Database
Option Explicit

Public NoGood As Long

Public Sub NoGoodSub()
Dim NoGood As Long
NoGood = 44
End Sub

Public Sub WrongGood()
NoGood = 33
NoGoodSub
Debug.Print NoGood
End Sub
==================================


Execute WrongGood in the immediate debug window, and you should get, as
result, 33, not 44, even if subroutine NoGoodSub has been run AFTER the
assignation to 33, and seems to make the assignation

NoGood = 44

but that assignation refers to the locally defined, inside the procedure,
NOT to the global variable of the same name. Having use


====== Standard Module Module3 ===
Option Compare Database
Option Explicit

Public NoGood As Long

Public Sub NoGoodSub()
Dim NoGood As Long
NoGood = 44
End Sub

Public Sub WrongGood()
Module3.NoGood = 33 '<=== here
NoGoodSub
Debug.Print Module3.NoGood '<=== here
End Sub

============================


would have removed any confusion, since now, the two variables collision has
been resolved: That assumes that the standard module name is module3.



Vanderghast, Access MVP
 
Very few experienced people here use Macro's to code
their applications.

This is partly because many of the people here have long
experience, and new features like Access 2007 TempVars
are new.

And partly because many of the people here have long
experience, and have already worked out that VBA is
more powerful and flexible.

Macros will do
all of what all people want most of the time,
all of what most people want all of the time,
most of what all people want all of the time,
but not all of what all people want all of the time, and once
you have the VBA there isn't any point in also having Macro's.

From your point of view, one of the effects of this is that many
of the most helpful people here don't actually have much experience
with Macro's and don't have an opinion about TempVars.

(david)
 
There might be some gray areas between Good and Evil, Kari. :-)

TempVars are suitable for some scenarios, but not others. They were
introduced to enhance the macro language in Access, so that more things
could be done without needing VBA code.

Advantages:
=========
- Using TempVars in macros is more flexible, e.g. it does not require a
trusted application, and lets you build templates.

- TempVars can be read in contexts where VBA variables cannot, e.g. in
macros, queries, or in the control source of a text box on a form or report.

- TempVars don't lose the value when you reset your code while debugging.
(VBA global variables do.)


Disadvantages:
============
- They work only in Access 2007. If your application must support users on
older versions too, you can't use them.

- Like global variables, it is too easy to overwrite them (e.g. where 2
parts of a program use the same name and so interfere.)

- In general you want to develop with variables that have the narrowest
scope and shortest lifetime you need.
 
Let's put it this way - No President has ever used them and they are not
spoken of within the Catholic church - what do you think?
 
Thank you Michel, David and Allen. I have learned several valuable bits of
info from your discussion.

1. TempVars were created to be used in Macros. I'm not sure if this is a
good thing or not. It may just give beginners enough rope to hang themselves
with, or it may keep them out of VB where they can do some real damage.
Nonetheless, it's good to know. And it leads to #2:

2. If you're using VB don't use TempVars. If they were created for use in
Macros they will probably do something unpredictable at some point, under
some circumstances when used in VB.

3. Scope is very important when chosing what type of variable to use. I'm
assuming that TempVars are a Class-Object scope variable when they are
created in a macro within a Form and a Procedure scope variable when they are
created in stand alone macros, correct?

4. Finally, Allen Browne provided us with a overview of some of the
specific pros and cons to be considered when using Temp Vars.

Conclusion: Although TempVars are useful in some cases (primarily in
macros) serious developers (i.e. those who are comfortable with VB), or those
headed in that direction, will probably be better off with other types of
variables.
 
Kari, I'm not aware of any potential damage: your #2 is not substantiable
AFAIK.

Re #3, the scope is global/public (wider than just a class object.)

To rephrase your conclusion: if you are working in VBA, it would be
preferable to use a variable with the narrowest scope and shortest lifetime
(e.g. declared within a procedure.)
 
All good, but although I know I'm being picky, I don't agree with this:
they will probably do something unpredictable at some
point, under some circumstances when used in VB.
Click to expand...

As a general programming rule, when you have lots of different
options, you choose one and stick with it. This makes your
code easier to understand.

I have choosen to program in VBA using VBA variables
and Records and Form Properties, not using Database
Variables and TempVariables, but it's not because I think
TempVars are any more unpredictable than anything else.

I just don't need them, and I'm trying to keep the code simple
by limiting the different things I do.

If I was working with a 2007 application that was mostly Macro's,
even if I had to add some VBA, I would use existing TempVars,
and avoid creating new VBA variables.


I've used several features over the years that have been broken
by new versions of Access: Form properties, Transactions,
Compilation Constants, |embedded access values|, etc, and I'm
sure there are many others I never noticed, so I'm not going to
say that using any feature of Access is without risk, but there is
no reason to expect anything worse than usual.

(david)
 
dch3,

Are you feeling better now that the election is over? ;-)

Thank you for your response; a lot can be said, and enjoyed, through humor.

Kari
 
David and Allen,

Thank you both for checking back and commenting on my conclusions. I find
it interesting that you both disagree with, and considered it important
enough to comment on, my remark about TempVars being potentially
unpredictable outside of macros. Even so, I don't know that I would retratct
it. Maybe I'm just shell-shocked with Access (my first brush with Access was
with one of the early versions that went kafluie when the file size got
large-ish). But since they were created for use in Macros they may not have
been tested extensively in the VBA environment. And, as David pointed out,
there is the specter of MS not supporting them; I might add, "Especially in
VBA."

Since TempVars have such broad scope (thanks for the clarification Allen)
they can trip you up that way (as seen in Michel Walsh's post, earlier).
And, of course, you should always use the narrowest variable that will work
for a given situation. So I think my conclusion stays the same: Use
TempVars only in macros (only as needed) and Global Variable in VBA (only as
needed).

I like David's idea of picking one option and sticking with it. Having had
to tinker with legacy code before, I try to think of ways to make life easier
on whoever inherits my code. Originally I was trying to stick with Macros,
figuring those would be easier for someone with limited knowledge to maintain
(and since I was re-learning Access (after a long absence) at the same time,
it was easier to build macros than code VBA). Unfortuantely, I found that I
couldn't acheive what I wanted with them. So now I'm learning, coding and
trying to figure out "best practices" all at the same time. Thanks for your
help on all three! :-)

Kari
 
Back
Top