[AccessD] Compact and Repair on Close

jwcolby jwcolby at colbyconsulting.com
Mon Dec 31 07:58:17 CST 2007


Rocky,

My understanding is that the C/R on close is for the database that is
closing.  Thus the FE if the FE is closing, the BE if the BE is closing.
The answer now depends on how you use the FE.  

In my case I copy the FE from the server every time the user opens the FE.
This sounds expensive but in fact copying a 9 meg file takes about 2 or 3
seconds at most over a gig lan.  So, since in my case the user gets a fresh
copy every time, there is absolutely no point in doing a c/r as the FE
closes.  

Other people use a system with a version number and only copy the FE if the
version changes up on the server.  Now the FE could sit on the user's PC for
days, weeks, months or years without ever being re-copied.  In that case it
would probably be a good idea to c/r the FE on close.

In any case you can avoid the time of the C/R in the close by sensing that
it is running on your dev machine and not doing the C/R in that case.  I
have code that gets the machine name.  So something like 

	if MachineName() <> "M90" then
		'Do the C/R here
	end if

IIRC you can also check whether a FE is an MDE.  I don't remember how, but
if you can find that code then you could put a similar check in it.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at
Beach Access Software
Sent: Monday, December 31, 2007 8:34 AM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] Compact and Repair on Close

	 
Dear List:
 
I have a legacy app that was set up to compact and repair on close.  I found
it annoying during development - the delay every time I closed and re-opened
the app.  So I disabled it.  The program will eventually become an mde and
will be distributed to a vertical market.
 
Q: is there any reason to C&R on exit?  I know it gets rid of the 'bloat' -
but IME that bloat is mostly inconsequential in terms of execution time.
There are very few front end tables in this app - it's all back end.  Or is
there some other good reason to turn this C&R on Exit feature back on?
 
MTIA
 
Rocky
 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list