Recordsets and bloat

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

Guest

Hi all

Quick question. If I declare a recordset variable (Dim rst As
DAO.Recordset), but due to the conditional logic of the code don’t actually
set it to a recordset (e.g. Set rst = CurrentDb.OpenRecordset(SQL), does the
recordset variable contribute to bloat? Should it be released somehow?

Many thanks

David
 
David,

Not sure what the answer is, but why don't you declare it right before
you open it, so it's also declared conditionally - so not declared at
all, if the recordset is not required?

Nikos
 
It won't bloat.

If never set, the object will be Nothing, and will go out of scope (memory
will be released) when you exit the procedure.
 
Hi Nikos

The IDE won't allow a variable with the same name to be declared more than
once in the same module, and I don't want to keep on having to think up new
names for the same recordset.

Thanks

David
 
Also, Nikos recommended dimming the variable just before using it. That is
bad coding practice. All dimming should be done at the top of the module or
procedure; otherwise, it can be hard to find.
And, as Allen pointed out, if you don't use it, there is no baggage.
 
Set rst = Nothing
in the procedure's single exit point (you do have just one exit point,
right?) 1) does no harm if you never set it in the first place 2) eliminates
any doubt 3) is a excellent habit to get into especially if followed
religously for all object variables.

HTH,
 
Amen

George Nicholson said:
Set rst = Nothing
in the procedure's single exit point (you do have just one exit point,
right?) 1) does no harm if you never set it in the first place 2) eliminates
any doubt 3) is a excellent habit to get into especially if followed
religously for all object variables.

HTH,
Click to expand...
 
Also, Nikos recommended dimming the variable just before using it. That is
bad coding practice. All dimming should be done at the top of the module or
procedure; otherwise, it can be hard to find.
Click to expand...

That's how I grew up, and in Pascal I don't think one had the choice.
But some authorities nowadays (e.g. Steve McConnell in the second
edition of _Code Complete_) recommend declaring and initialising
variables just before they're first used. The argument is that otherwise
things can be hard to find<g>.

So I'm begining to think of this as a question of different programming
styles rather than of good or bad practice. What do you think?
 
I would have to disagree with Steve McConnell. I am sure it makes no real
difference in efficiency. Declaring variables and setting constants within
executable code, to me, just makes following the code a little more
difficult. If you use a good naming convention that includes data type and
scope, there is no confusion on how a variable is used. One other thing I do
when declaring variables is put a comment in that describes the use of the
variable. So, if there is any question when reading my code, you only have
to go to the top of the procedure or module to see what the variable is for.
I don't use global varialbes.
It is arguable that it is a matter of style. I can't disagree with that. My
intention when writing code is to make it as easy for the person behind me to
understand what I was doing. That includes making code as simple as possible.
I was told by my mentor in 1977 that a beginner's code and a seasoned
expert's code will be very simular. The difference being that the expert's
code would be tighter and more efficient. It is the programmer in the middle
of his learning experience that is hard to follow. He is learning all the
cute tricks and using them because he can, not because the problem requires
it. I have found that to be very true. When you see code that has complex
nested formulas and immediate Ifs, then you know that person has about 2 to 3
years experience. Someday he will have to modify that code and realize what
a nightmare he created.

So, to sum it up, it is all about style and personal preference to a point.
There are somethings, however, almost everyone can agree are bad practices,
like the infamous GoTo. So, the idea is to watch, learn, and share. We all
get better that way.
 
That's how I grew up, and in Pascal I don't think one had the choice.
But some authorities nowadays (e.g. Steve McConnell in the second
edition of _Code Complete_) recommend declaring and initialising
variables just before they're first used. The argument is that otherwise
things can be hard to find<g>.
Click to expand...

Hi Klatuu, John
'-----------------------
Option Explicit

Sub Test()
cb = "cb"

Dim cb As String

Debug.Print cb

End Sub

'-----------------------

It's all a question of scope.

A typo won't be caught by "Option Explicit" if a variable of the same name
has been declared before the typo.
This means that using Dim before the block of code allows inadvertent use to
be detected.
The corresponding case using a variable after the block of code it was
declared for cannot be detected.

Some languages allow variables to become undefined,
so that inadvertent use can be detected;
sort of like "UnDim MyVar".

Regards John
 
That's a very good point, John. That issue alone should be enough to kill
off Steve McConnell's idea.

If you reuse variables (e.g. strSQL gets reused in so many procedures I
write), the concept of applying a variable immediately before use cannot be
consistently applied.
 
'-----------------------
Option Explicit

Sub Test()
cb = "cb"

Dim cb As String

Debug.Print cb

End Sub

'-----------------------

It's all a question of scope.
Click to expand...

I must be missing something because I can't see the problem. If there's
no variable cb in scope, the
cb = "cb"
assignment won't compile, and if there is one then the
Dim cb As String
won't compile. Either way, the error message is clear.
A typo won't be caught by "Option Explicit" if a variable of the same name
has been declared before the typo.
This means that using Dim before the block of code allows inadvertent use to
be detected.
The corresponding case using a variable after the block of code it was
declared for cannot be detected.
Click to expand...

These are good reasons for always giving variables the smallest possible
scope ... something I don't always manage in practice.
 
Umm, err Allen <covers mouth with fist and coughs politely>

The example shows the opposite behaviour.

Still there is dynamic typing in the older Lisp dialects were the
very existence of a variable was due to the path the program took.

Regards - John
 
Back
Top