TempVars vs Type Variables (1 Viewer)

NauticalGent

Ignore List Poster Boy
Local time
Yesterday, 22:30
Joined
Apr 27, 2015
Messages
6,286
Hello folks,

Seeking some advice/opinions. I have it in my head that TempVars are bad practice - not sure where it came from but the consensus here at AWF seems to be to avoid them.

My current job has be going over and documenting the existing App/Code. While doing so, I came accross this:

Code:
TempVars("EmployeeType") = rs!EmployeeType_ID.Value
TempVars("Identifier") = rs!Identifier.Value
TempVars("BuyerCode") = rs!BuyerCode.Value
TempVars("OfficeSymbol") = rs!OfficeSymbol.Value
TempVars("Name") = rs!Name.Value

In the past I would achieve the same results with this:

Code:
Public Type UserInfo
  UName As String
  EMail As String
  JobTitle As String
  LogDate As Date
End Type
 
Public uInfo As UserInfo       'Declare a GLOBAL Instance of the User Defined type

And then enumerate them with:

Code:
Dim MyDB As DAO.Database
Dim rst As DAO.Recordset
 
Set MyDB = CurrentDb
Set rst = MyDB.OpenRecordset("SELECT * FROM Employees WHERE [EmployeeID]=1", dbOpenSnapshot)    '1 Record
 
'Fill the Enumeration/User Defined Type
With rst
  uInfo.UName = ![LastName]
  uInfo.EMail = ![email]
  uInfo.JobTitle = ![Title]
  uInfo.LogDate = ![HireDate]
End With
 
rst.Close
Set rst = Nothing

My questions are: Do TempVars get a bad rep or should they be avoided? Is one method better than the other?
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 02:30
Joined
Sep 12, 2006
Messages
15,614
I've never got into the habit of using them, but I think it's a matter of taste. One benefit is that they retain values in the event of a program crash. Also they come with intellisense, I think.
 

Isaac

Lifelong Learner
Local time
Yesterday, 19:30
Joined
Mar 14, 2017
Messages
8,738
I think they are too easy to use and discourage people from understanding what they are actually doing.
I still use global variables - they work fine.

Honestly, though - my personal preferences aside - they're not "bad" (like MVF's or something). I just think they obfuscate things and make it foggier to see through, which I always stay away from stuff like that myself.
 
Last edited:

Gasman

Enthusiastic Amateur
Local time
Today, 02:30
Joined
Sep 21, 2011
Messages
14,048
I have always thought of them as just another form of global variable?
 

NauticalGent

Ignore List Poster Boy
Local time
Yesterday, 22:30
Joined
Apr 27, 2015
Messages
6,286
I've never got into the habit of using them, but I think it's a matter of taste. One benefit is that they retain values in the event of a program crash. Also they come with intellisense, I think.
Thanks Dave, I read that bit about retention too. If everything else comes down to a matter of taste then TempVars would seem to be a better option. I have read somewhere that they can be used in queries too so there is that...
I think they are too easy to use and discourage people from understanding what they are actually doing.
I still use global variables - they work fine.

Honestly, though - my personal preferences aside - they're not "bad" (like MVF's or something). I just think they obfuscate things and make it foggier to see through, which I always stay away from stuff like that myself.
Isaac! It seems it IS possible for you and I to communicate outside of the WaterCooler....who woulda thunk it?!?! Thanks for the input.
I have always thought of them as just another form of global variable?
Paul, agreed. One of the frustrating things (to me at least) about VBA is that there seems to be about 10 different ways to do the same thing. To CopyPasters like me, it makes me wonder if one way is better than the other and why is there so many options??? Maybe I am over-thinking too much....

MarkK once provided a nifty Class Module that accomplished the same thing but it seemed like a bit of overkill. I guess the big question is that does one method carry a bigger "hit" on resources over the other...is there even a way to determine this?
 

MajP

You've got your good things, and you've got mine.
Local time
Yesterday, 22:30
Joined
May 21, 2018
Messages
8,463
The big differences from Tempvars and all others you mentioned is that they do not go out of scope on an unhandled error and more importantly they are a collection. You can loop, count, add, remove, and call by index. That does provide a lot more flexibility over types and globals.
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 19:30
Joined
Oct 29, 2018
Messages
21,358
As others already mentioned, TempVars is like a Global Variable with the main difference that you won't need a helper/wrapper function to access them outside of VBA and that they don't lose their content during a session reset. Also, I think custom Types are only accessible through VBA.

I use TempVars a lot more now than Global Variables, because I like using them in query parameters.

Just my 2 cents...
 

NauticalGent

Ignore List Poster Boy
Local time
Yesterday, 22:30
Joined
Apr 27, 2015
Messages
6,286
Good stuff guys, appreciate your time...
 

MajP

You've got your good things, and you've got mine.
Local time
Yesterday, 22:30
Joined
May 21, 2018
Messages
8,463
Actually I totally missed that benefit. But I think what @theDBguy mentions for use in query is probably the real reason they exist.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 02:30
Joined
Sep 12, 2006
Messages
15,614
Yes I forgot about the benefit with tempvars, of not needing a function to read a variable in a query. That's what comes from not using them!
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 22:30
Joined
Feb 19, 2002
Messages
42,981
One of the frustrating things (to me at least) about VBA is that there seems to be about 10 different ways to do the same thing.
There's a book written by an old friend named Gerald Weinberg called "The Psychology of Computer Programming". It is more of a psychology book than a technical one and it talks about how programmers work. One of his points is that some computer languages are better than others and the worst ones are like VBA which give you way too many ways of doing the same thing.

I don't like tempvars for two reasons -
1. you have to remember to use their .value property in some cases
2. people define them all over the place. Use a little discipline and make a module specifically for defining tempvars and make it easier on the people who have to look at your code later.
 

NauticalGent

Ignore List Poster Boy
Local time
Yesterday, 22:30
Joined
Apr 27, 2015
Messages
6,286
Use a little discipline and make a module specifically for defining tempvars and make it easier on the people who have to look at your code later.
I took your advice on that aspect- A Public Function called LoadTempVars() - and it has made a world of difference.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:30
Joined
Feb 28, 2001
Messages
27,001
Pros: Usable in a query; retain values after a debug event leads to a code reset; behaves like a normal (if limited) collection

Cons: Cannot use with objects. Cannot have more than 255 of them. The .VALUE property must be a string or a number. And I'm not clear on whether the number can be anything OTHER than some integer data type.

I am a pragmatist. To me they are just another tool in the tool box. For certain situations they make sense. For others, they don't quite fit. However, I will add that I have never found a situation where I absolutely had to use them. As has been pointed out, VBA gives you a lot of different ways to "skin a cat." <<<MEOW!!!>>>
 

Gasman

Enthusiastic Amateur
Local time
Today, 02:30
Joined
Sep 21, 2011
Messages
14,048
Pros: Usable in a query; retain values after a debug event leads to a code reset; behaves like a normal (if limited) collection

Cons: Cannot use with objects. Cannot have more than 255 of them. The .VALUE property must be a string or a number. And I'm not clear on whether the number can be anything OTHER than some integer data type.

I am a pragmatist. To me they are just another tool in the tool box. For certain situations they make sense. For others, they don't quite fit. However, I will add that I have never found a situation where I absolutely had to use them. As has been pointed out, VBA gives you a lot of different ways to "skin a cat." <<<MEOW!!!>>>
tempvars("cash")=22.578999
? tempvars!cash
22.578999
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 22:30
Joined
Feb 19, 2002
Messages
42,981
I took your advice on that aspect
I'm glad you took my advice for organizing them but I wasn't recommending their use. I dislike them immensely and don't use them unless I can't avoid it.
 

Gasman

Enthusiastic Amateur
Local time
Today, 02:30
Joined
Sep 21, 2011
Messages
14,048
I'm glad you took my advice for organizing them but I wasn't recommending their use. I dislike them immensely and don't use them unless I can't avoid it.
I saw them first just as a Global variable that I could use in queries, and populate from various places.
Then I started using them to hold data for the session, like UserID, UserLevel etc

As @The_Doc_Man said, just another tool to use. :)

I started life off as an engineer. If someone created an all singing alldancing new spanner/wrench, I wouldn't say 'We always used a ratchet' :)
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 22:30
Joined
Feb 19, 2002
Messages
42,981
A long time ago, I started leaving the login form open and hidden and that was were I held all my variables. I don't see anything that TempVars can do that my method doesn't so I never adopted. Besides, I really hate having to remember to use .Value when referencing them.
 

Gasman

Enthusiastic Amateur
Local time
Today, 02:30
Joined
Sep 21, 2011
Messages
14,048
A long time ago, I started leaving the login form open and hidden and that was were I held all my variables. I don't see anything that TempVars can do that my method doesn't so I never adopted. Besides, I really hate having to remember to use .Value when referencing them.
Yes, that is an anomaly, but in queries you do not need to.?
You already had a set routine, so the old adage, 'if it ain't broke don't fix it' applies :)

However I never had that, so when they came along and I only started Access with 2003, I could see I could use them for the purposes I mentioned above.?

Same as table lookups. the first DB I created I used them. I did however realise what they were doing, and I have left that DB alone. To my mind no point changing it, for the sake of changing it. I understand what is happening and it works as I want it to, I understand the limitations.

However, I have not used them since. :) rofl
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 21:30
Joined
Feb 28, 2001
Messages
27,001
Just as Pat had a login system, so did I, and because I had implemented privileges and other sorts of things that caused my number of "things to remember after login" to balloon out of sight, I just kept them in public set of variables in a general module dedicated to security. I don't recall whether it would have exceeded the 255-item limit, but I didn't stick around to find out.

Thanks for the clarification on floating-point, gasman. It's a question that hadn't ever come up and at the time I answered that question, my wife was calling me downstairs for a spot "honey do" task.
 

Gasman

Enthusiastic Amateur
Local time
Today, 02:30
Joined
Sep 21, 2011
Messages
14,048
I will not know most of the limitations of a tempvar anymore, as I have retired and was at best, an admin person trying to use Access like a lot of people that come here an other forums.?

Now and again something posted intrigues me, so I investigate futher. Sady I will have forgoten it in a few minutes time, but if I have posted it, I can at least search for it? :)

I have made the error, numerous times, when Access complains it cannot set an object for TempVars :(
 

Users who are viewing this thread

Top Bottom