Given that you split your database, and each user's front end only has non-data objects (forms, reports, queries), I would recommend not checking this option.
Given that you split your database, and each user's front end only has non-data objects (forms, reports, queries), I would recommend not checking this option.
There have been reports of compact on close causing problems with your database. However I have always had it checked and allow my databases to compact on close, and I've never had a problem.
In certain circumstances, compact on close can cause corruption.
Its far less common now than used to be the case 20+ years ago, but I wouldn't risk it either.
It will just slow down closing your FE database for little benefit.
As Isaac said there should be little need to compact the FE in a split database as it shouldn't get 'bloated'
From my point of view as a developer, I find it best to have compact on Close switched on because as you develop the database it does get bloated as you add and delete things.
I would agree that if you release it to your customer, then it's probably best to have it switched off.
The best way to tackle the possibility of corruption whilst developing is to make regular backups, because at some stage you are likely to get some sort of corruption...
Yes I see your point, but I split my databases early on during the development cycle and prefer to have control over when compacting is done.
If I were to implement compact on close, I would also implement creating an automatic backup before closing