ansaurus

Question

Answer 1

A:

He settled. The correct way to store global variables is to use a module.

http://www.blueclaw-db.com/access_database_global_variable.htm
http://forums.whirlpool.net.au/forum-replies-archive.cfm/528616.html
http://www.google.com/search?q=global+variables+in+vba+access

bugtussle 2010-08-10 18:10:48

Global variables are reset if an unhandled error occurs, so they are chancy.

Remou 2010-08-10 18:18:35

Global variables are a terrible way to handle something like this. Fake security is also not a good design (which is what it sounds like is being used).

David-W-Fenton 2010-08-11 00:38:30

@David What's the lesser of two evils?

Ben McCormack 2010-08-11 03:57:07

I don't know which two evils you are asking about. The basic design outlined in the original question sounds bad both in WHAT is being implemented and in HOW it is implemented.

David-W-Fenton 2010-08-11 20:44:26

Answer 2

A:

As bugtussle has said you can use "global" variables inside modules. Here's how:

Create a module called LoginCredentials. Inside that module, you can declare variables as public, which in effect makes them global variables. For example:

public LoggedInUserId As Integer
public IsUserLoggedIn As Boolean

You can set and access those variables from other forms. I prefer to always use the module name with the variable name in VBA so I know where the globals are declared, like so:

LoginCredentials.LoggedInUserId = 15

If LoginCredentials.IsUserLoggedIn Then
    'Do Something    '
End If

Granted, global variables only persist for the life of the application, so if it crashes or the user exists the application, you'll lose that data. If you need the login credentials to "live" longer, consider storing the data in a database table.

As a side note, it's not at all uncommon for your OOP-oriented brain to hurt a little when working with VB6 /VBA. The language simply fails to fully implement OOP design features, but it's still possible to write better code when you know what you're doing.

Ben McCormack 2010-08-10 18:19:10

As I said, global variables are reset if an unhandled error occurs, so they are chancy.

Remou 2010-08-10 18:21:58

@Remou Did you miss the part of my answer, "so if it crashes or the user exists [sic] the application, you'll lose that data" and then suggest that he should consider storing data in a table? You bring up a good point about unhandled errors, but he should be handling errors, or at least adding it as he goes. I see Tony's point that if it's working, you may not need to fix it, but at the same time it's not a bad idea to look at other options.

Ben McCormack 2010-08-11 00:33:56

They aren't reset if it's an Access MDE/ACCDE.

David-W-Fenton 2010-08-11 00:37:37

@Ben McCormick No I did not miss your point, my point is that this is a completed application that the OP has just been assigned to on a temporary basis and he or she may not have the time to check all the code to ensure that there are no unhandled errors, furthermore, the OP states that he or she is unfamiliar with VBA, so it may be a larger commitment of time than is acceptable.

Remou 2010-08-11 06:31:54

@Remou That's a good point. In general, I agree with the "if it ain't broke, don't fix it" model when you inherit legacy code, but God help you if you ever do have to fix it :-).

Ben McCormack 2010-08-11 11:28:00

Answer 3

+2 A:

This method is perfectly functional as global variables can be reset to null given code interruptions and such. Especailly while you the developer are working in the code.

Also if it's working now why change it?

Tony Toews 2010-08-10 21:13:32

ansaurus

tags:

views:

answers:

MS-Access Cross-Form Support

related questions