<mirandacascade@yahoo.comwrote in message
news:155f6bdf-8194-4760-8a46-109133131078@t1g2000pra.googlegroups.com...
Quote:
Question toward the bottom of this post....background information
Quote:
My application (a reporting system) does the following:
>
1) at the beginning of a session, sets up a querydef
2) when a user requests a report the application sets up the querydef;
Perhaps you just bind the report to a linked table and pass the parameters
using a where clause? A linked odbc table should run about as fast anyway.
(unless there is multi-table joins).
Quote:
5) the Access application takes the result set and uses it as the
recordsource for an Access report object.
Are you assigning query in the reports open event? (not clear how you doing
the above). Remember most bloat occurs when you modify objects in design
mode and then save them. So, if your modifying the report, you want to avoid
this.
Quote:
6) at the end of the session, the application 'cleans up', i.e. it
deletes the querydef that it established at the beginning of the
session
Actually why delete it? That just creates a hole like deleting a file on you
hard disk that then needs defragmenting. Simply leave the query in place.
And, just modify it for next time. You can often reduce bloat this way.
Quote:
a) the application never adds/deletes/modifies records in any of the
Access tables
Fine, but does it open any object like a form, or report, or query in design
mode and then save it?
I would suggest you run the application as a mde (that way, code can't
become un-compiled, and you reduce chances of bloat that way. it is a MUST
to install the jet sp3 serviced pack, and the sr2b update to office. Both of
these can significantly reduce your bloating problems, and in some case near
eliminate them.
Quote:
b) the application never creates/deletes temp tables
It not just tables, but any object you flip into design mode or modify and
save will cause bloat.
Quote:
So, when one looks at the database window in the 8MB app, one sees the
same objects as when one looks at the database window in the 20MB
app.
>
So, finally, my questions...they have a theme of 'where will I notice
the bad side effects?"
1) will it take longer to load the 20MB bloated app than it will to
load the 8MB compacted app?
For the most part no. ms-access only loads the parts it using. So, if you
have a table with 1 record in it, or 300,000 records it in it , and you
simply load the ms-access application, that whole table is NOT loaded into
memory. So, thus the load time access is should be the same.
Quote:
2) will it take longer to a load form in the 20MB app than it will to
load the same form in the 8MB app?
Again, no. I suppose perhaps over a LONG period of time it might slow down a
bit, but for the most part the load time should remain fairly constant.
Quote:
3) will it take longer to load a report in the 20MB app than it will
to load the same report (with the same result set as recordsource) in
the 8MB app?
Once again...no it should not.
Quote:
4) I understand that a 20MB bloated app occupies more space on disk,
but are there other negative side effects of having a bloated app?
Yes, you substantially increase the chances of corruption as now there are
1000's of objects in the access application that must be maintained. It much
like driving in rush hour traffic, you much increase your chances of a
accident since your dealing with more cars (or in our case objects). You can
run an applcation with 1 user for 5 years, but if you have 5 users running
it, then you have 5 times the chance of a problem. So, a table with 1
million reocrds has more chances of being damanged then a table with 2
reocrds. It quesiton of probablbiy and chance. So, more stuff and more bloat
means that the system is stressed more in terms of the number of objects.
Quote:
5) Does everything run slower in a bloated app, or is the slow down
(if there is, in fact, a slow down) happen only when the application
is first loaded?
Well it should not, but it likely does a small amount. (generally not be too
noticed). There will be more "objects" to deal with in the application, but
access does a very good job of ignoring that extra stuff (and, we not really
processing bound these days).
One way to ensure code does not un-compile is to use a mde. And, mde's tend
to run a bit faster also. Note that a great side effect of a mde is that
un-handled code errors don't blow out local, or even global variables (your
application just keeps chucking along). So, mde's tend to make your
application more reliable.
Like anything else, if you don't change the oil in your car, it will not
blow up, but eventually it good idea to adopt some type of maintains
schedule for tat car, or in his case regular compacting of the front end. I
have some clients that go for 6 months, but then again I taken care to not
have any bloat...and usually a new update is issued to them before a
compact/repair is needed anyway.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com 
