TempVars; Why and What?

Guus2005

AWF VIP
Local time
Tomorrow, 00:32
Joined
Jun 26, 2007
Messages
2,642
I got an application in which they used TempVars a lot.
Since i have never had the lack of pleasure of not having to use them i will have to now!

So i was wondering why did M$ added the TempVars collection?
Is it a special collection with added features and if so what are those features?
Or is it a plain vanilla collection?
I believe the scope of the TempVars collection is global, am i right?

Thanks for your time!

[edit]It is not a plain vanilla collection because it can only hold numbers and strings. So why add it in the first place?[/edit]
 
Last edited:
I have no idea, I have just avoided them because I could! Watching this thread so I can get educated too
 
I use tempVars a lot. I use them to save application wide variables.
They behave like a global variable, and they don't reset as long as the application is running.

When a user logs in to the database, I read several items from option table and set several tempvar. So I don't need to DLookup different user's preferences over and over when I need them. I keep userID, Username, Interface language, preferred printer or preferred form to show the result of search, and several other options in different Tempvars.
 
Last edited:
Though I knew about them, I have not had problems that required their use. But if I recall correctly, they persist after a RESET operation. Could be wrong about that, but ...

Let's say you were debugging code that had user info in public variables in a general module and you get one of those dreated pop-ups that offer you the chance to DEBUG or RESET. If you pick RESET then the variables are reset too. But I believe TempVars don't reset so you could continue working with the values you had set in them.

It was precisely because they are limited in what they can store that I never used them. I was always storing complex data types (created via TYPE statement) which were unsuitable for TempVars.
 
I have never used them either, mainly because I took a different approach before I knew about them. That approach was to write code for a user object and that object had all the properties I needed, like FName, LName, EmplNo, email, Lvl etc. so all I needed to write was e.g.
If dbUser.Lvl >= 4 Then

It's more code for sure, but not too hard to add properties if the need arises. The upside is that you can have any property which may not be a member of TempVars. The downside might be that you'd need more objects.

A guy I knew who was the go-to guy for Access in our division was using TempVars. He called me one day to say that his tempvar code for logged on user stopped working and he couldn't see why, so he was going with user objects after that. That's mainly why I never took a liking to them.
 
Hi. Just one person's humble opinion here, but I started using TempVars as soon as they became available only because it overcomes the problem of resetting all global variables when a runtime error occurs. The following are some other benefits I could think of, off the top of my head:
  1. Available in queries
  2. Can easily add new ones (on the fly)
  3. Variable data type (no objects though)
  4. etc...
Just my 2 cents...
 
I haven't used TempVars much, but when I did I found it a pain to have to type it out every time.

So I added a module with:
Code:
Option Compare Database
Option Explicit

Private m_tv As TempVars

Public Property Get tv() As TempVars
  If m_tv Is Nothing Then Set m_tv = TempVars
  Set tv = m_tv
End Property

Then I could just use the shorthand 'tv':
Code:
' Immediate Window:
tv("uid") = Environ("username")
?tv("uid")
DM

hth,

d
 
As a matter of policy, I still don't use TempVars precisely because they persist after a serious error.
Instead I continue to use global variables where appropriate.

AFAIAC, the fact that global variables are lost after a serious error is useful during development work because it indicates a problem that needs fixing.
I don't want that information to be 'masked'.

By the time that my apps are distributed to clients, it shouldn't matter as all such errors have (hopefully) been fixed.
 
>> By the time that my apps are distributed to clients, it shouldn't matter as all such errors have (hopefully) been fixed. <<
Famous last words! ;)
 
A few years ago I noticed a problem with tempvars. I Blogged about it on my website:- Tempvars Value Error I'd welcome feedback from anyone saying whether they've had the same experience. I'd be interested to know if it is duplicatable on your machine..
 
@cheekybuddha
I did say....hopefully.
However in several of my schools apps, I included an error logging feature that (with clients' permission) silently sends me an email with full details of any error (who/what/where//why/how etc) in order to assist with any fixes requires. Its almost two years since I last received any such error emails which I call success....
 
>> I'd welcome feedback from anyone saying whether they've had the same experience. <<

Yes, now you mention it, I seem to remember this. Perhaps this is why I have never really used them since.
 
TempVars always were a solution looking for a problem.

It is a persistent myth that VBA variable are lost during errors. DocMan explained the facts above.
 
Just to be clear cheekybuddha --- (And anyone else I give the love "Like" to) it's not that I fancy you or anything, I recently was given one of these love "Like" myself, and I got a trophy, and a nice lot of points with it! So I'm hoping it's giving you a trophy and at least I think, 25 or 30 points! Now if you really liked this answer, how about a bit of LOVE!
 
My use is similar to Tera's.

On load of my login form, I detect the Windows user ID with the Windows API, which determines whether or not they will be allowed to proceed (depending if it is found in the Users table). On clicking login, I set a TempVar called CurrentUserID that is = to their UserID in the Users table. UserID is just the primary key of the user, so numbers 1-20 or so. I then use CurrentUserID in various places:

On starting a new data entry form, txtUserID's Default Value =[TempVars]![CurrentUserID]. The field is also disabled so you can't enter records impersonating another employee.

On opening the data entry form:

Code:
'Only creator of the record can edit:

    Me.AllowEdits = (CurrentUserID = Me.txtUserID)
    Me.sbf.Form.AllowEdits = (CurrentUserID = Me.txtUserID)

    Me.cmdDelete.Enabled = (Status = New) And (CurrentUserID = Me.txtUserID) And (Not IsNull(Me.[Inspection ID]))
    Me.cmdComplete.Enabled = (Status = New) And (CurrentUserID = Me.txtUserID) And (Not IsNull(Me.[Inspection ID]))
    Me.cmdEdit.Enabled = (Status = Complete) And (CurrentUserID = Me.txtUserID) And (Not IsNull(Me.[Inspection ID]))

    If CurrentUserID = Me.txtUserID And Status = New Then
        Me.sbf.Form.AllowAdditions = True
        Me.sbf.Form.AllowDeletions = True
    Else
        Me.sbf.Form.AllowAdditions = False
        Me.sbf.Form.AllowDeletions = False
    End If

As criteria in the User ID field of a record list's record source query: [TempVars]![CurrentUserID]

To determine privilege levels:

Code:
Option Compare Database
Option Explicit

Public Enum PrivilegeEnum
    ReadOnly_Privilege = 1
    Inspector_Privilege = 2
    Analyst_Privilege = 3
    Administrator_Privilege = 4
End Enum

Private Function EmployeeHas(UserID As Long, RoleID As PrivilegeEnum) As Boolean
    EmployeeHas = DCountWrapper("*", "tblUsers", "[User ID]=" & UserID & " AND [Role]=" & RoleID) > 0
End Function

Public Function IsReadOnly() As Boolean
    
    IsReadOnly = EmployeeHas(GetCurrentUserID(), ReadOnly_Privilege)

End Function

Public Function IsAnalyst() As Boolean
    
    IsAnalyst = EmployeeHas(GetCurrentUserID(), Analyst_Privilege)

End Function

Public Function IsAdministrator() As Boolean

    IsAdministrator = EmployeeHas(GetCurrentUserID(), Administrator_Privilege)
    
End Function

Public Function GetCurrentUserID() As Long
    GetCurrentUserID = Nz(TempVars![CurrentUserID], 0)
End Function

There are many uses...
 
I use global variables and functions in almost exactly the same way e.g variable lngUserID, functions GetUserID, GetUserName etc.
 
I have found them useful for some of the reasons stated above though isladog's comments in post#8 have me second guessing. :) I use them for user settings such as window props, logged in user, machine name, control visibility/availability, etc. I have found that wrapping them in properties in a static module provides typing, a read-only option and also lists all my tempvars in intellisense. This is a great site. A lot of talent here. I recognize some of your avatars from searching out answers over the years. I appreciate the free help!

Uncle Gizmo. Yes, I have had the same issue. The same thing occurs when trying to use an object as a key or item in a dictionary. I have learned to use Field.Value or the dictionary grabs a reference to the field object itself. I suppose that this would apply to controls as well.
 
Last edited:
I have a question related to the use of TempVars.

Sometimes I can't figure out how to just use them directly. It's like I have to set a regular variable first.

JSX:
Private Sub Form_Load()

    On Error Resume Next

    Dim CurrentUserID As Integer
        
    CurrentUserID = TempVars(CurrentUserID).Value
    
    Me.txtComment.Locked = (CurrentUserID <> Forms!frmInspection.txtUserID)
    Me.txtComment.Locked = (CurrentUserID <> Forms!frmInspectionList.cboInspector)

    If IsNull(Me.Recordset("Comment")) Then
        Me.txtComment.SetFocus
    End If
End Sub

Anyone know why?
 
Hi. This looks like, without testing it, a circular reference.
Code:
CurrentUserID = TempVars(CurrentUserID).Value
To your issue though, are you saying you can't do this?
Code:
Me.txtComment.Locked = TempVars("TempVarName") <> Forms!frmInspection.txtUserID
If not, what error message do you get?
 

Users who are viewing this thread

Back
Top Bottom