Are Global Variables Really that bad ?

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
 
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?
A lot of people, many of them on this forum are stuck in boxes. As it turns out I apparently don't know the difference between Public Variables and Global Variables. Be it as it may my database are driven by queries. Public Variables as Public Functions are a great way to write SQL code, It's clean, concise, and runs fast. I'm not trying to convert anyone, don't care to save the world, but experts make the worst example of closed mindedness.

Edison and Westinghouse are excellent examples of that, just ask Tesla.
 
A lot of people, many of them on this forum are stuck in boxes. As it turns out I apparently don't know the difference between Public Variables and Global Variables. Be it as it may my database are driven by queries. Public Variables as Public Functions are a great way to write SQL code, It's clean, concise, and runs fast. I'm not trying to convert anyone, don't care to save the world, but experts make the worst example of closed mindedness.

Edison and Westinghouse are excellent examples of that, just ask Tesla.
Of course, many developers will stick to the same approaches which they have used for years.
I'm sure that I'm guilty of that to some extent and it sounds like you are as well
Sometimes, its hard for all of us to accept that there may be better methods available to us.

I'm not going to get involved in whether I think what you are doing is / isn't good practice.
However, if you re-read my comments at the beginning of this lengthy thread, you may get some idea of my viewpoint back in 2017

Whatever the merits (or otherwise) of your approach, you seem to be demonstrating exactly what you are referring to here
i.e. being 'stuck in boxes' and 'closed mindedness'
 

Users who are viewing this thread

Back
Top Bottom