Preventing Global variables from being reset

[ramprat]

Hi All,

I currently need to store 3 variables to be used as global variables throughout my application. I need to record the username, their employee group and the task they are doing. The username, for example, is entered into a field on a table to indicate who last worked on that particular record. I have created the code below and it seems to work fine except when the application occasionally errors out at which point the global variables lose their values. Is there a way to prevent the global variables from being reset until the database is closed? I've researched online but haven't found what I'm looking for yet. Also, just curious, but in a multi-user environment these global variables must obviously be local to a particular machine so that if two people log in at the same time they both have their own name stored in their own global variable. Is this true? If so, are these stored within the memory of each local machine?

The code below is in my Globals module

 
Option Compare Database
 
Global g_username As String
Global g_group As String
Global g_task As String
Public Function Init_Globals()
g_username = ""
g_group = ""
g_task = ""
End Function
Public Function get_global(gbl_parm)
Select Case gbl_parm
        Case "g_group"
             get_global = g_group
        Case "g_username"
             get_global = g_username
        Case "g_task"
             get_global = g_task
End Select
End Function

On my Login Form I ask the user to pick their name, employee group and task they will be performing from a set of 3 combo boxes. I record these values with the click event of a button on the form as follows :

 
g_username = Me.USERNAME
g_group = Me.Group
g_task = Me.Task_Combo_Box

[Stewart Ross]

Hi ramprat. Global variable values are inherently volatile if faced with untrapped code errors, as in these circumstances the VBA code is reset and their values are lost. Of course, all VBA code should have appropriate error handlers to prevent such interruptions.

Further, globals are not shared between instances of Access running on different PCs - they are purely local to the current instance as they are set and read within the active PC's memory.

Simplest thing to do is to store the shared values you need to refer to in an Access table instead. Local values such as username could remain global, but if you are writing some values to a reference table it may be as simple to write them all.

-Stewart

[DonRayner]

I could be wrong on this, but I believe that as soon as access encounters an errors without any form of error handling all the global variables get reset. If you want to avoid this issue you are going to have to implement error handling routines in all of your subs.

[DonRayner]

Oops too slow again. I realy have to work on my typing speed. ;)

[ramprat]

Thanks Stewart.

I thought of that but thought that it might affect performance by always writing to a table. Also, I've already got more tables than I'd like in my database so I was hoping to avoid adding another if possible. Also, being a multi-user environment will that table not get overwritten each time someone logs in? If not, I suppose I could create a table called temp_globals and populate it with the values at login and then I could implement code something to the effect of (I'm not sure if I have the syntax right but this is the general idea every time I need to reference one of the global variables) It's a crude form of error handling in the vein of what Don suggested. Would this work or am I out in left field here?

Thanks

 
if isnull.get_global("g_username") = false then
 
     Me.USERNAME = get_global("g_username")
else
     Me.USERNAME = [temp_globals]![username]
 
end if

[Stewart Ross]

Hi ramprat. I don't recognise the syntax you are using - the isnull function does not use dot notation for instance - so I'm not sure whether what you have written will work or not. I'd suspect not, of you are really trying to use IsNull that way!

You would need to set and clear values from your temporary table using a combination of VBA and SQL approaches. Not difficult, but as I don't know your requirements the way you do I can't advise you how to achieve what you intend here. Suffice to say that you can insert and modify rows for each logged in user as they open and close the database by using appropriate event handlers to do so.

Performance is very, very unlikely to be an issue here - I would not worry about that at all.

-Stewart

[ramprat]

I guess it would be better to use

if get_global("g_u sername") = "" then

etc


I was hoping to create a table with only one record in it. It would be the record for the current user. I imagine this would then be visible to all users and more importantly would get overwritten each time someone logs in unless instead of a table I wrote the current username to a text file on the local C drive and then used this value whenever the global variable got reset.

[Megalog]

If you're running this as a networked application, with each user having their own front end file, why not just use a local table to store the user globals? Then when the application starts, you delete all records in the table, and then populate the single new record with data retrieved from the login form you use. No need to mess with a text file (that they can delete).
Then, you can either redirect your global procedure to call on the table data, or, do a null check on the global and if it passes as true, refresh the global with the stored table data.

[ramprat]

Unfortunately it is a single database that everyone accesses at the same time.

[Megalog]

You need to consider splitting your database into Front End/Back End files, and distributing the front end to your users. If you're concerned at all with performance, this would be the first thing I'd do. Also, you're asking for corruption by having multiple users logging into a single standalone database.

[ChipR]

I use global variables in my application, and obviously they are lost when an unhandled error occurs, but I have error handling on every procedure and test as much as possible before I release. Wouldn't you be doing both of these things anyway?
From what I've read, having multiple users access a single database is risking corruption. Separating the front end from the back end is a simple click away.

[ramprat]

forgive a seemingly dumb question but I've never split a database before. When I split a database the wizard creates a backend database for me holding nothing but the tables. How do I then link a front end database to this? Would I have to create a database with links to the tables in the back-end

[Megalog]

I hope we arent getting too far off topic, but for a quick answer here is NeoPa's article on db splitting. This is the manual how-to, but the wizard I assume does pretty much all of this (creates the BE file, and a proper front end with table links and content).

http://bytes.com/topic/access/insights/737435-front-end-back-end-fe

As always, back it up before you try any of this.

[ramprat]

Thanks Megalog. I appreciate you helping out the less experienced

[NeoPa]

I hope we arent getting too far off topic, but for a quick answer here is NeoPa's article on db splitting. This is the manual how-to, but the wizard I assume does pretty much all of this (creates the BE file, and a proper front end with table links and content).

Good point Megalog.

I've added to the thread to explain this now ;)