compact on close

  • Thread starter Thread starter Ben
  • Start date Start date
B

Ben

Hi all,

How doe the "compact on close" work, if the mdb file is being used over a
network with multiple user having the file open at the same time? Does it
compact based on information from the ldb file, meaning, once the last user
logs out, it start to compact ? I don't suppose it tries to compact when
there's other user still have it open right? Thanks.

Ben
 
Compact on close is just like compacting manually. If there's one or more
users in the database, it won't work. But when the last user closes it, it
will compact. Keep in mind though that it applies to the *.mdb being used -
so if you're using a Front End/Back End design (as you should) with the Front
Ends on a person's local machine, compact on close will compact the Front End
since only that user is using the Front End *AND* because its on the users
personal machine.
 
dch3,

Thanks. That's what I was looking. I just want to know that if the mdb
would compact after the last user closes out. Thanks, again.

Ben
 
There is an issue you need to be aware of.
You did not say whether the shared mdb on the network is a backend database
for for a multi user application that the users are linking to from a front
end application or if you are commiting the hideous sin of multiple users
sharing an unsplit database on a server.

If it is the later, then, yes when the last user closes the mdb, it will
compact. If you are correctly configured and the mdb is a back end database,
then it will not compact when the last user closes the application. You will
need to periodically compact and repair the mdb.

If you are sharing an unsplit database on a network, you really need to
split the database and deploy it correctly.
 
You should also be aware that many feel that compacting is often
the cause of corruption
Click to expand...

I would not say that. But compacting a database that is already
corrupt *can* cause that database to lose data, or in some other way
end up unusable. That risk makes use of COMPACT ON CLOSE completely
unacceptable (aside from the fact that it's pretty useless to
repeatedly compact a front end, given that all multi-user apps
should be split).
 
We all agree here, but I do want to comment on your statement regarding front
ends not needing to be compacted. In general and usually, I would agree;
however, there are times where a front end can suffer to some degree from
bloat. If there are any procedures in a front end that create temporary
tables in the front end, bload can occur. It is not reasonable to say that
no tables should ever be used or created in a front end. There are times
when it is advantageous.

If you have such an application, rather than compact and repair, a valid
practice is rather than start the app directly, run a .bat file that copies a
clean copy of the app each time it is started up. This has two advantages.
First, it will never have bloat, and the user will always have the most
current version. There is no need to use an front end updater or send out
new versions via email.
 
Back
Top