Are Global Variables Really that bad ?

From Pat:
I get called in to clean up lots of messes.

For about the first 5 to 10 years of my stay with the U.S. Dept. of Defense, my biggest job was cleaning up other people's messes. Which is probably why both Pat and I use globals when needed, but with trepidation because of the dangers inherent. Solo, you will say that this is group-think or prejudice. I must respectfully - but emphatically - tell you that it is called experience.

In 40+ years of computing in private and public environment, I have learned a few things about the fine art of software engineering. You don't only code something to work - but you code it to work well and you code it to be re-usable because otherwise you are pitching dollars down the "wishing it would work" wishing well. It has been my experience that you must constrain the urge to globalize too many things.

Solo, your viewpoint as you express it is, I am sure, heartfelt and in your mind it must seem clear. To my way of seeing it, you are arguing in favor of practices that I have seen to be expensive (in the "time is money" sense of that term.)

You KNOW if you read my posts that I use globals - but only when carefully designed and limited in subject matter. Please understand that I am not saying to never use globals. But I am saying that they are like having feral cats as pets - they will do their business where you least expect it and stink up the place. Not to mention they will attack you when you least expect it. Whereas if you have a place for your globals, it's like a litter box, a place to contain the stink. OK, I use colorful metaphors sometimes, but it's the way I am.

One thing I will say that is important here is simply this: It's a poor tool kit that doesn't have very many tools in it. Globals are just one way to track things. Tempvars are another. And the problem with having too few tools in the kit? If all you have is a hammer, everything you've got gets nailed.
 
I've never used global variables in a database application. Why would you need a bunch of values sitting in memory when you can load them in, unless you're on a very poor network?

I don't think there's any excuse for unhandled errors, especially if you know you're going to release an MDE/ACCDE.
Trying to sell program crashes as a solution to poor coding is just silly.
 
I would classify the loosing of global values on unhandled errors as a program bug. It has been present in Access for so long I'm sure that MS classifies it as a feature. Rather than fix the bug, they created TempVars!
 
Ah, yes. Microsoft learned that trick from Digital Equipment Corporation in the 1990s when DEC was still in business and MS had a teaming agreement with them.

"It's not a bug, it's a feature!" That was the mantra on DEC PDP-10, PDP-11, and VAX/VMS products - my wheelhouse as it were. Brings back old memories.
 
Wicked, I know! But I thought it would be amusing to resurrect this thread.. .


(The wife's SALES shopping, and I'm sat in Costa with nothing better to do)
 
Beyond this link to a more recent thread about the topic, there is not much I have to add.
-> Passing global/public variable between forms
Of all the replies on that thread, Galaxiom's words resonate with me:
Procedures are like a building. Work to be done should be delivered and results returned through the front door. Global variables are the equivalent of doing business through a window with an itinerant passerby. It is a disaster waiting to happen.

Succinct and on-point.
 
Procedures are like a building. Work to be done should be delivered and results returned through the front door. Global variables are the equivalent of doing business through a window with an itinerant passerby. It is a disaster waiting to happen.

If you've ever played music in a bar on Bourbon Street in New Orleans, you know that the open window is exactly how they do business during holiday crowds where the building has a customer capacity placard - but the streets don't. That time-honored hot-weather treat, the "snowball" (a.k.a. snow cone) is also vended from an open window. It may or may not be a disaster, but it IS a strategy for unusually high volumes of contact.

Before any of the newer members ask, ... Yes, I played organ in a bar on Bourbon Street during New Orleans Mardi Gras seasons back in the late 1960s and early 1970s. It is how I paid my way through college without incurring massive student debt. I don't recommend it as a career sufficient to support a family, but as a bachelor living at home with my parents, it kept the bill collectors - and the wolf - away from the door.
 
I'll go back and read some of this.
If by Global you mean Public, then they are the one of the best ways to build an Access Database.


The two big databases Construction and Chemical Plans Management that I built have hundreds of Public Variable, never had a single problem with them carrying over an incorrect value, never had a single debugged problem yet. With 10s of thousands of uses, and millions of clicks later.

The reason many developers don't like them is because during the debugging phase, (probably made worse by too much error code) public variable loose their value when the system hiccups. If you build a system that has bugs, you will not like Public Variables. My code doesn't have bugs (after the initial testing and debugging) because the code is so much simpler using queries and public functions.


You can have much simpler code, and your control over queries is much better with Public Variables. All of my queries either in SQL Code in modules, or Query Defs use Public Function derived from Public Variables


I tried to post the code but it was too long.

What you have to do is set the values of the Variables you will be using in the open statement for Forms.
 

Attachments

A poor design well implemented does not make it a good design. I doubt any database developer is going to agree that a database application with hundreds of public variables is a good design. Maybe someone will. I would be very interested if you find someone on this forum that agrees this is a good approach. I have no doubt that you can make this work, but most people will agree that there are better smarter ways. Encapsulation, data integrity, debugging, fault tracing, etc, etc. Back in the old days before Object Oriented programming and event driven programming there was no other way than maintaining lots of globals, I think those days are gone.

I can take the worst non-normalized database and slap on some slick forms and enough vba and people will think it is great. It will work great. But that does not make it good and would not recommend it.

There may be times to use a public variable, but most of the time there is a better way.

Not saying this is your case, because I am sure you are very knowledgeable. But in general when I see applications with lots of public/global variables the developer does not know (some or all):
1. How to pass arguments to procedures
2. How to return values from functions
3. How to build a parameterized query definition
4. How to pass and return values from forms
5. How to build custom classes
6. How to build user types
7. How to do enumerations

When a developer only has a hammer everything looks like a nail.

In Access if you absolutely need to use a global variable then use a TEMPVAR. I do not use TEMPVARS much, but if there was a pressing need to use a global variable then there is no reason not to use a TEMPVAR instead. (unless for some reason you need to have a global variable that is an object). A TEMPVAR was specifically made so that you can use it in a query without an additional function. TEMPVAR functions like a global variable but has advantages.
When I look at your file, I would assume all those values are coming from a table/s and could be easily accessed. So why you would need most of those variables?
 
Last edited:
While I do use public variables in general modules, I use them in moderation and with narrow purpose. My contention has always been that it is just another tool in the tool box. I do understand the old adage about "if all you have is a hammer, everything looks like a nail" and I try to use as many different tools as I have, each where appropriate. There are times when session-wide variables are appropriate. Using TempVars works for numeric and text variables, not for complex objects and structures. Passing ByRef works most of the time, but sometimes there is that oddball case. Let's just say while I prefer structure in my code, I won't ALWAYS avoid injecting a little chaos into my life. :LOL:
 
It was a good one. Lots of "how-to" with the DataVerse connectors. Karl D, Grover Park George and even Steve Bishop made an appearance...I grabbed a seat in the back of the classroom and hoped prayed the teacher wouldn't call on me.
Yeah right.... you spoke up more than once and made some very useful comments! :D
 

Users who are viewing this thread

Back
Top Bottom