- Local time
- Today, 14:49
- Joined
- Feb 28, 2001
- Messages
- 28,734
Let's also clear some air about "memory sensitive" issues.
TempVars are dynamically created memory-resident (ONLY) structures that occupy memory only if/when created. They grow and shrink in size according to use of the Add/Remove methods applied to the TempVars object.
Public (i.e. global) variables are usually statically allocated (when in general modules) or dynamically allocated (when opening a form/report with a class module) - but in class modules, you can call them Public but they aren't really public anyway. Both occupy space in the workspace virtual memory when instantiated.
The overhead is less for Public variables because of the TIME at which the references are made. The VBA Compiler has extensive symbol tables it uses when building the code but by the time the module gets loaded to memory, those symbol tables are generally not in play for the code. (They ARE in play for the debugger.) But the fact they are not in play for the code is why you can't make a run-time reference to a variable from an SQL statement. You have to build the statement first, THEN run the SQL as a separate step.
There is such a thing as a dynamically created OBJECT; i.e. you have an object variable for which you could use the object = NEW object-structure-name syntax. In that case, the object variable itself is static but the created structure is dynamically created in virtual memory.
So yes, there can be memory consumption differences between the two, but you use them in different ways and the "address binding time" is different, so expect that difference and don't sweat the small stuff. The BIG stuff is knowing that you have a system that allows you to have larger virtual images and that has enough swap space to support what you are doing.
TempVars are dynamically created memory-resident (ONLY) structures that occupy memory only if/when created. They grow and shrink in size according to use of the Add/Remove methods applied to the TempVars object.
Public (i.e. global) variables are usually statically allocated (when in general modules) or dynamically allocated (when opening a form/report with a class module) - but in class modules, you can call them Public but they aren't really public anyway. Both occupy space in the workspace virtual memory when instantiated.
The overhead is less for Public variables because of the TIME at which the references are made. The VBA Compiler has extensive symbol tables it uses when building the code but by the time the module gets loaded to memory, those symbol tables are generally not in play for the code. (They ARE in play for the debugger.) But the fact they are not in play for the code is why you can't make a run-time reference to a variable from an SQL statement. You have to build the statement first, THEN run the SQL as a separate step.
There is such a thing as a dynamically created OBJECT; i.e. you have an object variable for which you could use the object = NEW object-structure-name syntax. In that case, the object variable itself is static but the created structure is dynamically created in virtual memory.
So yes, there can be memory consumption differences between the two, but you use them in different ways and the "address binding time" is different, so expect that difference and don't sweat the small stuff. The BIG stuff is knowing that you have a system that allows you to have larger virtual images and that has enough swap space to support what you are doing.