Compact on Close only compacts/repairs tables in the database where it
resides, so if you add it to the front end, it will only compact local
tables in the user's copy of the front end. If you put it in the back end,
effects will be unpredictable, as it can only take effect when the database
in which it resides has no other users logged in.
Neither of the sizes you quote is exceptionally large for a Jet or ACE
database, but the compression does indicate there was a lot of
no-longer-used storage, and there's always the possibility of something
going wrong when there is "trash" lying around.
If you have a design such that there are no tables updated by the user in
the front end, then you could just download a fresh copy of the frontend
from a central repository rather than use Compact. That is the best way to
design your database application, in any case... if there are "per user"
values that need to be saved, they can be saved in the common back end in a
table that includes the user's id to identify them; if they are "per user
machine" rather than "per user", they can be in another set of linked tables
that are stored on the local machine. (That complicates re-linking tables on
startup, but doesn't make it impractical -- but it is an uusual situation.)
Larry Linson
Microsoft Office Access MVP
