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

Re-dimensioning string variable that has already been globally dimensioned...

P: n/a
MLH
I have a module named Declarations. In it, there is a line that reads:

Global MySQL As String

I decided to dimension it as a global variable after I was
already deep into development. I got tired of typing Dim
MySQL As String every time I wanted to use it in a
procedure for concatenating SQL needed for a RunSQL
statement.

Many of the Dim MySQL As String statements still exist
in my code, I found out today. I even have one in a function
procedure in another global module. Yet, when I compile
loaded modules with open modules containing this line of
code, the line doesn't usually produce an error. Is this the
way things are supposed to work?
Nov 13 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
There are pro's and con's for global declaration, especially
after the event as it were.

When a variable is Dim'd it is also initialised; Strings to
Null, int and lng's to 0 and so on. With a global public
declaration the variable in question will no longer be
initialised at the beginning of a procedure where it was
originally Dim'd unless you add a line to do it manually.

So a variable can then carry a value from procedure to
procedure. It's scope is global and that can cause
problems. I can't remember if hitting another Dim will act
to ReDim the variable and I don't think the compiler will
care if it hits a duplicate Dim.

You can locate instances of the string MySQL using the
search tool within Access' VBA editor, or use a third party
tool like SpeedFerret or whatever, then edit accordingly.

--
Nick Coe (UK)
www.alphacos.co.uk

---

"MLH" <CR**@NorthState.net> wrote in message
news:vi********************************@4ax.com...
I have a module named Declarations. In it, there is a line that reads:
Global MySQL As String

I decided to dimension it as a global variable after I was
already deep into development. I got tired of typing Dim
MySQL As String every time I wanted to use it in a
procedure for concatenating SQL needed for a RunSQL
statement.

Many of the Dim MySQL As String statements still exist
in my code, I found out today. I even have one in a function procedure in another global module. Yet, when I compile
loaded modules with open modules containing this line of
code, the line doesn't usually produce an error. Is this the way things are supposed to work?

Nov 13 '05 #2

P: n/a
Yes, this is the way things are supposed to work.

It is possible to have a local variable with the same name as a global
variable.
While the local variable is in scope, the global one can't be accessed.
This is all well-defined and raises no errors.
Think of it this way -
you're not really re-declaring the same variable; you're creating a new
(more temporary) one.

It looks as if in your case, you're not really trying to preserve the value
of the variable across the procedures, just re-using the memory space it
occupies.
In that case, it won't make any difference whether you're using the global
variable or the local one.

As Nick mentions, though, you need to be careful (especially if you're
building the string) about what you assume is in it initially.

HTH
- Turtle

"MLH" <CR**@NorthState.net> wrote in message
news:vi********************************@4ax.com...
I have a module named Declarations. In it, there is a line that reads:

Global MySQL As String

I decided to dimension it as a global variable after I was
already deep into development. I got tired of typing Dim
MySQL As String every time I wanted to use it in a
procedure for concatenating SQL needed for a RunSQL
statement.

Many of the Dim MySQL As String statements still exist
in my code, I found out today. I even have one in a function
procedure in another global module. Yet, when I compile
loaded modules with open modules containing this line of
code, the line doesn't usually produce an error. Is this the
way things are supposed to work?

Nov 13 '05 #3

P: n/a
"MacDermott" <ma********@nospam.com> wrote...
While the local variable is in scope, the global one can't be accessed.


Actually, it can be accessed, with the <module name>.<variable name> syntax.

--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
Windows International Division

This posting is provided "AS IS" with
no warranties, and confers no rights.
Nov 13 '05 #4

P: n/a
MLH <CR**@NorthState.net> wrote in
news:vi********************************@4ax.com:
I have a module named Declarations. In it, there is a line that
reads:

Global MySQL As String

I decided to dimension it as a global variable after I was
already deep into development. I got tired of typing Dim
MySQL As String every time I wanted to use it in a
procedure for concatenating SQL needed for a RunSQL
statement.

Many of the Dim MySQL As String statements still exist
in my code, I found out today. I even have one in a function
procedure in another global module. Yet, when I compile
loaded modules with open modules containing this line of
code, the line doesn't usually produce an error. Is this the
way things are supposed to work?


A local duplicate declaration creates a new variable with the same
name. This is by design.

I have my own strSQL variable, but I never use a global for it,
because I sometimes test the length of it, and if I'm doing that,
I'd have to be sure I set it to a ZLS at the beginning of each
subroutine where I'm testing its length before concatenating
something with it.

A simple search and replace should allow you to eliminate all the
declarations you want to remove.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.