By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,961 Members | 2,492 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,961 IT Pros & Developers. It's quick & easy.

Preventing Global variables from being reset

P: 60
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
Expand|Select|Wrap|Line Numbers
  1.  
  2. Option Compare Database
  3.  
  4. Global g_username As String
  5. Global g_group As String
  6. Global g_task As String
  7. Public Function Init_Globals()
  8. g_username = ""
  9. g_group = ""
  10. g_task = ""
  11. End Function
  12. Public Function get_global(gbl_parm)
  13. Select Case gbl_parm
  14.         Case "g_group"
  15.              get_global = g_group
  16.         Case "g_username"
  17.              get_global = g_username
  18.         Case "g_task"
  19.              get_global = g_task
  20. End Select
  21. End Function
  22.  
  23.  
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 :

Expand|Select|Wrap|Line Numbers
  1.  
  2. g_username = Me.USERNAME
  3. g_group = Me.Group
  4. g_task = Me.Task_Combo_Box
  5.  
  6.  
Jan 20 '09 #1
Share this Question
Share on Google+
14 Replies


Expert Mod 2.5K+
P: 2,545
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
Jan 20 '09 #2

DonRayner
Expert 100+
P: 489
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.
Jan 20 '09 #3

DonRayner
Expert 100+
P: 489
Oops too slow again. I realy have to work on my typing speed. ;)
Jan 20 '09 #4

P: 60
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
Expand|Select|Wrap|Line Numbers
  1.  
  2. if isnull.get_global("g_username") = false then
  3.  
  4.      Me.USERNAME = get_global("g_username")
  5. else
  6.      Me.USERNAME = [temp_globals]![username]
  7.  
  8. end if
  9.  
  10.  
Jan 20 '09 #5

Expert Mod 2.5K+
P: 2,545
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
Jan 20 '09 #6

P: 60
I guess it would be better to use

if get_global("g_username") = "" 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.
Jan 20 '09 #7

Megalog
Expert 100+
P: 378
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.
Jan 20 '09 #8

P: 60
Unfortunately it is a single database that everyone accesses at the same time.
Jan 20 '09 #9

Megalog
Expert 100+
P: 378
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.
Jan 20 '09 #10

Expert 100+
P: 1,287
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.
Jan 20 '09 #11

P: 60
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
Jan 20 '09 #12

Megalog
Expert 100+
P: 378
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/insigh...nd-back-end-fe

As always, back it up before you try any of this.
Jan 20 '09 #13

P: 60
Thanks Megalog. I appreciate you helping out the less experienced
Jan 20 '09 #14

NeoPa
Expert Mod 15k+
P: 31,492
@Megalog
Good point Megalog.

I've added to the thread to explain this now ;)
Jan 28 '09 #15

Post your reply

Sign in to post your reply or Sign up for a free account.