Access Network question

[Arvin Meyer [MVP]]

For some of my clients MDBs I've noticed that they take up 40 Mb of
RAM on startup. With only loading two forms. So I suspect Access is
loading all the VBA code into RAM on startup.

Some time ago, it may have been more than 10 years ago, I remember being
told by someone at Microsoft that when you called a VBA sub or function, the
entire module was loaded into memory. So rather than single large modules
for every like typed code, it was preferable to load often used functions
into the same module, and keep the modules separated by usage frequency and
code affinity. IOW, It doesn't necessarily make sense to put all the string
functions in 1 module and date functions in another unless you are doing it
for storage or cataloging purposes.

 

[David W. Fenton]

AFAIK it's the code that is a blob. The objects themselves,
tables, queries, forms, reports and macros are individual objects.

Hmm. I'm not sure about that. I assumed this was the reason why you
lose accurate update tracking on all objects in A2K and later. Given
that the module of a form is part of the form, I wouldn't expect it
to be stored somewhere else. I mean, when you SaveAsText, you don't
get one file for the form and one for its module -- it's all one
thing.

 

[David W. Fenton]

Some time ago, it may have been more than 10 years ago, I remember
being told by someone at Microsoft that when you called a VBA sub
or function, the entire module was loaded into memory. So rather
than single large modules for every like typed code, it was
preferable to load often used functions into the same module, and
keep the modules separated by usage frequency and code affinity.
IOW, It doesn't necessarily make sense to put all the string
functions in 1 module and date functions in another unless you are
doing it for storage or cataloging purposes.

That was true before Access 2000. It is no longer true since then.

And, frankly, I never thought there was much reason to worry about
that, since it's been a long time since we really had to worry about
memory usage/performance at that level. In other words, doing that
always seemed to me like premature optimization.

 

[Tony Toews [MVP]]

Hmm. I'm not sure about that. I assumed this was the reason why you
lose accurate update tracking on all objects in A2K and later. Given
that the module of a form is part of the form, I wouldn't expect it
to be stored somewhere else. I mean, when you SaveAsText, you don't
get one file for the form and one for its module -- it's all one
thing.

Then we are going to agree to disagree.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

Some time ago, it may have been more than 10 years ago, I remember being
told by someone at Microsoft that when you called a VBA sub or function, the
entire module was loaded into memory. So rather than single large modules
for every like typed code, it was preferable to load often used functions
into the same module, and keep the modules separated by usage frequency and
code affinity. IOW, It doesn't necessarily make sense to put all the string
functions in 1 module and date functions in another unless you are doing it
for storage or cataloging purposes.

Given that it might've been more than ten years ago this might've been
before A2000. I suspect your description was accurate in A97 and
earlier. But not in A2000 and newer.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Arvin Meyer [MVP]]

Hmm. I'm not sure about that. I assumed this was the reason why you
lose accurate update tracking on all objects in A2K and later. Given
that the module of a form is part of the form, I wouldn't expect it
to be stored somewhere else. I mean, when you SaveAsText, you don't
get one file for the form and one for its module -- it's all one
thing.

Hmm! And when you view the code in the IDE, the collection is all code, and
no form/report objects, so your argument can be refuted on the same basis.
If you were to save any code, individually, or as a collection, it would not
include any other objects. VB6 frx files, are the same as an Access form
definition files generated by SaveAsText, storing the form and code
definitions together, but maintaining them separately. I always assumed,
that they were using the same methodology. There are only a few people who
might know for sure. I've emailed one of them. Hopefully, I'll get an
answer.

 

[Arvin Meyer [MVP]]

I got a quick answer. This one is definitive, coming from the most senior
member (seniority-wise) of the Access Team at Microsoft:
=================
Arvin,

It is good to hear from you.

There isn't one answer for all of Access' different object types. But when
it comes to forms and reports, the data is stored in a few different places:

1) We store the form "template" (i.e. the layout of the controls,
properties, etc.) as a binary blob.
2) We store a bunch of type information for programmability as a separate
binary blob associated with the form.
3) We store the form's module in both text and binary forms along with the
VBA project.

The last part is important--all modules, form modules and class modules are
stored together. It used to be different with EB (ahhh the good old days)
but with VBA this is the best model, all things considered.

Let me know if you have any more questions.
=================

So there you have it.

--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[hor vannara]

This assumes that Access has smart logic for pulling data out of the
BLOB field where all of those (except for queries) are stored. I
don't know that there is such logic, but it's certainly possible.

 

[David W. Fenton]

Then we are going to agree to disagree.

Tony, it's not a matter of opinion -- someone (maybe quite a few
someones) at Microsoft know the answer to the question. Surely you
could ask someone about it?

 

[Arvin Meyer [MVP]]

Tony, it's not a matter of opinion -- someone (maybe quite a few
someones) at Microsoft know the answer to the question. Surely you
could ask someone about it?

I did, and the answer is posted a couple of posts down, at 12:58 PM EST.

All code is stored together. See the answer for specifics.