Steven said:Does it take up anymore memory or DB size if I have 6 mods or one mod with
6 funcitions? Would be the same amount of code.??
Marshall Barton said:Good point Graham!
There is some happy point between dumping everything into
one module and having a separate module for every
Function/Sub.
--
Marsh
MVP [MS Access]
It should be noted, however, that Access loads the entire module when any
procedure, enum, variable or constant in that module is referenced. For
example, if you have 100 procedures in a particular module, *all* of them
are loaded into memory even if you only use a single public variable which
is declared in that module.
This can result in slow Application, form or report load times if you
happen
to call a function that resides in such a large module.
Graham R Seach said:Yes. Having said that, though, a good technique to speed form/report loading
time, is to reference something from various modules when the application
loads. The app loads a bit slower, but the tradeoff is that the
forms/reports that use those procedures will load faster.
Personally, I tend to only have between one and five *related* procedures in
any module.
Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
Marshall Barton said:Good point Graham!
There is some happy point between dumping everything into
one module and having a separate module for every
Function/Sub.
--
Marsh
MVP [MS Access]
It should be noted, however, that Access loads the entire module when any
procedure, enum, variable or constant in that module is referenced. For
example, if you have 100 procedures in a particular module, *all* of them
are loaded into memory even if you only use a single public variable which
is declared in that module.
This can result in slow Application, form or report load times if you
happen
to call a function that resides in such a large module.
Steven Britton via AccessMonster.com wrote:
Does it take up anymore memory or DB size if I have 6 mods or one mod
with
6 funcitions? Would be the same amount of code.??
Not enough difference to matter. The best guideline is to
organize the Functions/Subs into modules in a sensible way
so that related calculations are together and independent
calculations are separated. However it is a fairly common
practice to place a bunch of small, unrelated functions in a
Utilities or Miscellaneous module.
Also note that moving a Function/Sub from one module to
another is very easy and rarely has a ripple effect.
The above does not apply to Class/Form/Report modules, where
the declarations and code define the class object.
Steven M. Britton said:Thanks to both of you, just curiosity and trying to expand my knowledge.
I
also didn't realize that when a form loads it pulls in everything from
that
Mod. I currently have my mods structured as you described *related* mods
together and utilities in its own.
So follow up question. On a form that has two button, one that closes the
form and the other that when clicked will call 3 different mods. When
that
form loads those three mods are loaded into memory, correct?
-Steve
Graham R Seach said:Yes. Having said that, though, a good technique to speed form/report
loading
time, is to reference something from various modules when the application
loads. The app loads a bit slower, but the tradeoff is that the
forms/reports that use those procedures will load faster.
Personally, I tend to only have between one and five *related* procedures
in
any module.
Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
Marshall Barton said:Good point Graham!
There is some happy point between dumping everything into
one module and having a separate module for every
Function/Sub.
--
Marsh
MVP [MS Access]
Graham R Seach wrote:
It should be noted, however, that Access loads the entire module when
any
procedure, enum, variable or constant in that module is referenced. For
example, if you have 100 procedures in a particular module, *all* of
them
are loaded into memory even if you only use a single public variable
which
is declared in that module.
This can result in slow Application, form or report load times if you
happen
to call a function that resides in such a large module.
Steven Britton via AccessMonster.com wrote:
Does it take up anymore memory or DB size if I have 6 mods or one mod
with
6 funcitions? Would be the same amount of code.??
Not enough difference to matter. The best guideline is to
organize the Functions/Subs into modules in a sensible way
so that related calculations are together and independent
calculations are separated. However it is a fairly common
practice to place a bunch of small, unrelated functions in a
Utilities or Miscellaneous module.
Also note that moving a Function/Sub from one module to
another is very easy and rarely has a ripple effect.
The above does not apply to Class/Form/Report modules, where
the declarations and code define the class object.