When are DIM's executed ???

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've heard that regardless of where DIM's are put in a procedure, they are performed at the beginning. Does this mean that the following code will cause a memory leak??

Do I really have to open and close a connection even when I dont want to

Private Sub Test(
If Me.Test = True The
Exit Su
End i
Dim cn as new ADODB.connectio
...
cn.clos
set cn = Nothin
End Sub
 
That is my understanding - all variables are instantiated
at the time of compilation.
I was taught as a VB developer not to use the New keyword
because it caused the 'Set cn = Nothing' statement to have
no effect. I was told that the object was destroyed but
was immediately instantiated.
Admittedly, that was more years ago than I care to remember
but I would be interested to know from the wiser sages who
contribute to this newsgroup whether that applies to Access
VB (or indeed whether it ever applied to VB at all)

Hope This Helps
Gerald Stanley MCSD
-----Original Message-----
I've heard that regardless of where DIM's are put in a
Click to expand...
procedure, they are performed at the beginning. Does this
mean that the following code will cause a memory leak???
 
As far as the Dim conn as New ADODB.Connection line goes:

AFAIK, (Could be wrong), the object is not initiated until
the first time you use it. You can trap that by having
your own class with a Class_Initilize subroutine.

But, it also might be a good idea to change that line to
two lines.

Dim conn as ADODB.Connection
Set conn = New ADODB.Connection


I also put all DIMS at the top of the routine, so anyone
else looking at the code (or me after a month or so),
knows where all the variables are. Also, I move the Set
statement to where I need it, so that I know exactly
when/where it gets called.

Again, this is all opinion, and I'm not 100% sure it's
accurate. But it meets my internal coding requirements.


Chris
 
Chris said:
As far as the Dim conn as New ADODB.Connection line goes:

AFAIK, (Could be wrong), the object is not initiated until
the first time you use it. You can trap that by having
your own class with a Class_Initilize subroutine.

But, it also might be a good idea to change that line to
two lines.

Dim conn as ADODB.Connection
Set conn = New ADODB.Connection


I also put all DIMS at the top of the routine, so anyone
else looking at the code (or me after a month or so),
knows where all the variables are. Also, I move the Set
statement to where I need it, so that I know exactly
when/where it gets called.

Again, this is all opinion, and I'm not 100% sure it's
accurate. But it meets my internal coding requirements.
Click to expand...

That matches both my understanding and my usual practice, though there
are times when I use the New keyword so that I can let the object be
instantiated if an when I need it. If there's some cleanup that I need
to do only if the object was instantiated, then I can use code like this
in my cleanup procedure:

If Not objMyObject Is Nothing Then
' it was created, have to clean up
End If
 
Well, if we're on the subject, what's the difference in
setting a uninitated object variable to nothing, and
checking first?

(unless you have other code that you need to do in the
object close, but that should be either in a .Close
method, or Class_Terminate subroutine.)

Just curious.

Chris
 
Chris said:
Well, if we're on the subject, what's the difference in
setting a uninitated object variable to nothing, and
checking first?

(unless you have other code that you need to do in the
object close, but that should be either in a .Close
method, or Class_Terminate subroutine.)
Click to expand...

I'm a practical programmer, not a VB purist, but to my mind, if all
you're going to do if it's not Nothing is set it to Nothing, you may as
well just set it without checking first. On the other hand, if the
object has a Close method that should be called, or there's some other
processing that should be done before destroying the object, then I'll
check and explicitly call the appropriate methods. I believe that an
object *should* take care of such things in its Terminate routine, but I
don't like to trust that it will. There have been bugs reported in the
past involving objects not cleaning up after themselves properly. Maybe
they've all been fixed now, and maybe they haven't.
 
I'd agree with you. On my objects, I like to expose
a .Close method, and also call it from the Terminate sub.
I was just wondering what your opinion was.


Chris
 
Back
Top