Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
As New ADODB.Recordset VS As ADODB.Recordset
- Thread starter jpreciado
- Start date
Here is a link discussing this very topic:
Swi
Swi
jpreciado,
Here's some piece of advice from on of the best (if not the best) Visual Basic author I know: Francesco Balena.
When at run time Visual Basic encounters a reference to an auto-instancing variable, it first determines whether it's pointing to an existing object and creates a brand new instance of the class if necessary. Auto-instancing variables have virtues and liabilities, plus a few quirks you should be aware of:
1 Auto-instancing variables obviously reduce the amount of code you need to write to be up and running with your classes. For this reason, they're often valuable during the prototyping phase.
2 Auto-instancing variables can't be tested against the Nothing value. In fact, as soon as you use one in the Is Nothing test, Visual Basic relentlessly creates a new instance and the test always returns False. In some cases, this could be the decisive factor in whether to stay clear of auto-instancing variables.
3 Auto-instancing variables tend to eliminate errors, but sometimes this is precisely what you don't need. In fact, during the development phase you want to see errors because they're the symptoms of other serious flaws in the code logic. Auto-instancing variables make the debugging step a little more obscure because you can never be sure when and why an object was created. This is probably the most persuasive reason not to use auto-instancing variables.
4 You can't declare an auto-instancing variable of a generic type, such as Object, Form, or MDIForm because Visual Basic must know in advance which kind of object should be created when it references that variable for the first time.
5 In some complex routines, you might declare a variable but never actually use it: this happens all the time with standard variables and with object variables too, but it creates a problem with regular (non-auto-instancing) object variables. In fact, if you create the object with a Set command at the beginning of a procedure, you might be creating an object—thus taking both time and memory—for no real purpose. On the other hand, if you delay the creation of an object until you actually need it, you could soon find yourself drowning in a sea of Set commands, each preceded by an Is Nothing test to avoid re-creating an object instanced previously. By comparison, auto-instancing variables are automatically created by Visual Basic only if and when they are referenced: In all other cases, no time or memory will be wasted without reason. This is probably the situation in which auto-instancing variables are most useful.
6 Finally, each time Visual Basic references an auto-instancing variable, it incurs a small performance hit because it has to check whether it's Nothing. This overhead is usually negligible, but in some time-critical routines it could affect the overall time.
In summary, auto-instancing variables often aren't the best choice, and in general I advise you not to use them. Most of the code shown in this chapter doesn't make use of auto-instancing variables, and you can often do without them in your own applications as well.
I have to let you know that there's nothing mine in this post. I took the above, word by word from the book "Programming Visual Basic 6.0" from Microsoft Press 1999, by Francesco Balena.
JC
_________________________________________________
To get the best response to a question, read faq222-2244!
Here's some piece of advice from on of the best (if not the best) Visual Basic author I know: Francesco Balena.
When at run time Visual Basic encounters a reference to an auto-instancing variable, it first determines whether it's pointing to an existing object and creates a brand new instance of the class if necessary. Auto-instancing variables have virtues and liabilities, plus a few quirks you should be aware of:
1 Auto-instancing variables obviously reduce the amount of code you need to write to be up and running with your classes. For this reason, they're often valuable during the prototyping phase.
2 Auto-instancing variables can't be tested against the Nothing value. In fact, as soon as you use one in the Is Nothing test, Visual Basic relentlessly creates a new instance and the test always returns False. In some cases, this could be the decisive factor in whether to stay clear of auto-instancing variables.
3 Auto-instancing variables tend to eliminate errors, but sometimes this is precisely what you don't need. In fact, during the development phase you want to see errors because they're the symptoms of other serious flaws in the code logic. Auto-instancing variables make the debugging step a little more obscure because you can never be sure when and why an object was created. This is probably the most persuasive reason not to use auto-instancing variables.
4 You can't declare an auto-instancing variable of a generic type, such as Object, Form, or MDIForm because Visual Basic must know in advance which kind of object should be created when it references that variable for the first time.
5 In some complex routines, you might declare a variable but never actually use it: this happens all the time with standard variables and with object variables too, but it creates a problem with regular (non-auto-instancing) object variables. In fact, if you create the object with a Set command at the beginning of a procedure, you might be creating an object—thus taking both time and memory—for no real purpose. On the other hand, if you delay the creation of an object until you actually need it, you could soon find yourself drowning in a sea of Set commands, each preceded by an Is Nothing test to avoid re-creating an object instanced previously. By comparison, auto-instancing variables are automatically created by Visual Basic only if and when they are referenced: In all other cases, no time or memory will be wasted without reason. This is probably the situation in which auto-instancing variables are most useful.
6 Finally, each time Visual Basic references an auto-instancing variable, it incurs a small performance hit because it has to check whether it's Nothing. This overhead is usually negligible, but in some time-critical routines it could affect the overall time.
In summary, auto-instancing variables often aren't the best choice, and in general I advise you not to use them. Most of the code shown in this chapter doesn't make use of auto-instancing variables, and you can often do without them in your own applications as well.
I have to let you know that there's nothing mine in this post. I took the above, word by word from the book "Programming Visual Basic 6.0" from Microsoft Press 1999, by Francesco Balena.
JC
_________________________________________________
To get the best response to a question, read faq222-2244!
jpreciado,
My bad! I forgot to mention that object variables declared using As New are referred to as Auto-Instancing variables. Thus, my post above is talking about the use of As New...
JC
_________________________________________________
To get the best response to a question, read faq222-2244!
My bad! I forgot to mention that object variables declared using As New are referred to as Auto-Instancing variables. Thus, my post above is talking about the use of As New...
JC
_________________________________________________
To get the best response to a question, read faq222-2244!
- Status
Similar threads
