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

Globals and system instability

P: n/a
DFS
Not sure whether it's bad programming practice or not, but I have a module
of globals I declare in each system:

Global ws As Workspace
Global db As Database
Global td As TableDef
Global rs As Recordset, rs1 As Recordset
Global rs2 As Recordset, rs3 As Recordset
Global ctl As Control
Global frm As Form, subFrm As Form
Global rpt As Report
Global qItem As QueryDef
Global menuObject As Object

Most of them get used in each Access app, so I don't feel bad about
instantiating them this way. Saves some development time and hassles.

In general:
* I Set the db object to CurrentDB when opening forms, and never Close it.
* I always Set and Close the recordset objects I use.
* I Set the frm references as necessary, but never reset them to Nothing.

I'm wondering if declaring and using Global objects this way contributes to
system instability? When my apps reach a certain arbitrarily large size
(lots of forms and code), I always, always get the dreaded corruption
screen.

Usually it's recoverable, but sometimes not. And it always causes me to
curse.

Thoughts?

Nov 13 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
I am not aware of the approach causing instability in terms of ms-access.

However, use of global as a general rule is frowned upon. It makes the code
less modular, generally harder to debug, and harder to maintain.

Further, it also tends to make the programming process harder, as you have
to ensure that no other code is using those variables. If other code needs
those variables at the same time, then you are toast. So, it may not make
your application less stable, but it is sure fire way to introduce hard to
find bugs, and increase general maintaining costs, and simply increases the
difficulty in moving code from on application to another.

Even worse, is what about importing and using other code? If you get name
conflicts, then again confusion arises.

Global variables should ONLY be used for things that need to be global. So,
for example, you do not want to use global to pass variables between forms
(besides, you can set a reference to the other form, and use any variables,
or procedures in that form anyway - so, you don't even have to pass
vars...just references the previous form).

So, yes, as general approach to software and programming, global are much
frowned upon. And, the approach makes your code MUCH MUCH less modular. If
you take only ONE of those routines, then all the global have to follow
(and, you got to figure out what global must be moved, and you got to go
find those global).

Further, how can you have two routines operating at the same time? If you
got global, then you can only have ONE routine that users the "ctl"
(control) variable at a given time. Really, next to impossible to maintain
such systems.

When a developer working for me brings code with UNNECESSARY globals, I send
the code back with instructions to remove them....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal
Nov 13 '05 #2

P: n/a
DFS
Albert D. Kallal wrote:
I am not aware of the approach causing instability in terms of
ms-access.
OK. Something is causing me mucho corruption, and it seems haphazard, but
I'm almost sure it's related to a module, as the .mdb will corrupt when I
try to compile a module, or load a form that uses a module.

It's very frustrating.
However, use of global as a general rule is frowned upon. It makes
the code less modular, generally harder to debug, and harder to
maintain.

Further, it also tends to make the programming process harder, as you
have to ensure that no other code is using those variables. If other
code needs those variables at the same time, then you are toast.
Nah. Just create another global, and increment it with a number...:)

So,
it may not make your application less stable, but it is sure fire way
to introduce hard to find bugs, and increase general maintaining
costs, and simply increases the difficulty in moving code from on
application to another.

Even worse, is what about importing and using other code? If you get
name conflicts, then again confusion arises.

Global variables should ONLY be used for things that need to be
global. So, for example, you do not want to use global to pass
variables between forms (besides, you can set a reference to the
other form, and use any variables, or procedures in that form anyway
- so, you don't even have to pass vars...just references the previous
form).
I use two "types" of globals: 1) Access objects as I listed in my original
post, and 2) a few string variables like cSQL (for character SQL statement).

I do mostly use form references to get things like ID values from tables.
But to reference the form itself, I often set and use a global called 'frm'.
But I never Set frm = Nothing. That was the point of my post: does
declaring and setting but not closing a variety of Globals introduce
instability? I would think not, but something's hammering my systems.
So, yes, as general approach to software and programming, global are
much frowned upon. And, the approach makes your code MUCH MUCH less
modular. If you take only ONE of those routines, then all the global
have to follow (and, you got to figure out what global must be moved,
and you got to go find those global).
Sure. So I start each new Access system I create with a standard set of
modules :

- General Declarations (includes the Globals)
- routines to manipulate Access objects
- routines related to file dialogs and browser
- things related to startup (disable built-in toolbars, etc)

A bit of it goes unused, but it's not much code.
Further, how can you have two routines operating at the same time? If
you got global, then you can only have ONE routine that users the
"ctl" (control) variable at a given time.
It's rare - next to never - that I need two routines to be running together.
If one is nested inside another, obviously I use Globals ctl1 and ctl2, etc.
Really, next to impossible
to maintain such systems.
It hasn't been a problem for me over the last 5-8 years. But in the past
year or so, I'm getting frequent corruptions whenever my Access projects get
large. I haven't been able to resolve it, and it takes too much time to
recreate the same system without the use of the globals. If that's what it
is.
When a developer working for me brings code with UNNECESSARY globals,
I send the code back with instructions to remove them....


Unnecessary is the key word. I like the judicious use of globals, but I may
try to reduce them as a test.

Thanks for the reply, Albert.

Nov 13 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.