MDBs Inflate

[Al Campagna]

Hello all,
My application runs on a network with PCs set up 2 different ways...

3 machines have a front-end mdb (Program) installed on their individual
PCs... and access the back-end mdb (Data) from the server.
Several other machines run both the Prog and the Data mdbs totally from
the server. (slower... I know... but that's the way it is for now.)

The folks who run both the Prog and Data from the server, are
experiencing a much higher rate of file size inflation. The Prog mdb that
resides on the server "grows" at a much faster rate than the Prog mdbs that
reside on individual machines. Transaction "activity" is similar for both
setups.

The application is in use 24/7, so finding slow times to compact the mdbs
can be a problem.

What might be causing that disproportionate inflation?
Are there any techniques we can initiate that would help the situation...
or can someone point me towards some information on dealing with mdb file
size inflation.

Thanks in advance
Al Campagna
Candia, NH

 

[John Vinson]

The folks who run both the Prog and Data from the server, are
experiencing a much higher rate of file size inflation. The Prog mdb that
resides on the server "grows" at a much faster rate than the Prog mdbs that
reside on individual machines. Transaction "activity" is similar for both
setups.

VERY interesting! I've had hints that this might be the case, but it's
very informative to hear a real-life example.

Why the frontend bloats at all is a bit obscure. My guess is that
Access creates temporary tables when it's unable to rapidly retrieve
the necessary data. Perhaps something about connecting to it over a
network (rather than directly) is causing slowdowns, making Access
create more temp tables... but I really don't know for sure!

Takehome message: try to avoid connecting to a frontend over a
network (unless you're using Citrix or some other terminal emulator
instead of running Access on one machine to run a database on
another).

 

[Al Campagna]

Thanks John,
I was thinking there would definitely be more "traffic" to control on the
"all-remote" setup, but I wouldn't expect that to affect the file size.
(like a 1K email getting larger due to packet insertion, self-checking
stuff.. etc.)
Seems as though "amount of traffic" is the big difference between the 2
setups.

And you're right, I don't get the whole bloating thing... especially the
Prog bloating. The Data grows at a fairly constant rate, but the Prog just
blows up to 50 MB (from 10) every 2-3 weeks on the server.
And yes... I'm aware that the "all-remote" setup is not the way to go,
but for now, I have to go with it.

Thankfully, this is more of an inconvenience than a serious problem...
but a poser nonetheless.

Thanks again,
Al Campagna
Candia Computer Consulting
Candia, NH

 

[Van T. Dinh]

Perhaps because there are a number of users sharing the
same Front-End on the server and all of these users create
temporary space on the same copy of the Front-End (on the
server). I would assume X users will do more processing
than 1 user and therefore create X times the amount of
temporary space which bloats the Front-End on the server.

Since the Front-End on the server is shared and (also 24/7
usage), Compact-On-Close is not going to work either.

Thus, I think each user needs a copy of the Front-End on
his / her desktop with the Compact-On-Close enabled.

Cheers
Van T. Dinh
MVP (Access)

 

[John Vinson]

Thus, I think each user needs a copy of the Front-End on
his / her desktop with the Compact-On-Close enabled.

Absolutely! <GMRITC>

 

[Al Camp]

Thanks John and Van,
As I relplied to John previously, I'm aware that the "all remote" setup
is wrong... and in "the best of all possible worlds" I would not have it
that way.
It does appear that The Prog inflates because it's responding to/keeping
track of multiple users, and fails to clean itself up when unloaded.
Thanks for your help... we'll just live with it for now.
Al Camp