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.
--
Dave Hargis, Microsoft Access MVP
"David W. Fenton" wrote:
> "Linq Adams via AccessMonster.com" <u28780@uwe> wrote in
> news:877f1d98b8480@uwe:
>
> > You should also be aware that many feel that compacting is often
> > the cause of corruption
>
> 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).
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>