Front End Bloat Keeps Happening

I will check for img files. Everything I've read advises against automatically compacting the DB on close when it is not a single-use DB, and mine is not.

Does the info you've read expound upon why auto-compact is a bad thing? I use this feature and if there is am imminent train wreck I wold like to avoid it!
 
The train-wreck is if the FE is shared rather than copied. If a private copy of the FE properly links to the shared BE, there is little or no harm to an auto-compact on exit of the FE file. If you share the FE file (literally by having many people able to open the same file on the common server where it is located), you have done nothing useful by performing the split.
 
Thanks to the clarification, and I completely agree; why split the DB if everyone is simply going to share the FE?

I have a VBA script that does an initial install on each user's local drive and then checks for updates before starting Access. A nifty little bit of code I got from this very site!
 
If the smallest you can make your database is still too big, then you are going to have to take out data to get it smaller.
 
#22
the reason I would not auto compact is that I tend to C&R after I have made a lot of changes, or when a data file has grown, to a larger size and I want to try to slim it down.

either way I have a rough idea of what it ought to be. So if a 8Mb database is now 25Mb, I might decide to do a C&R.

Now I don't want to try and rescue a trashed database, so I will almost certainly copy it first, just in case the C&R goes wrong, and then I will C&R it manually. All this is why I do not want to auto-run a C&R.

#24
it doesn't happen. I don't share databases. I add code that checks whether the drive letter is bigger than H (say) and is therefore (most likely) a network drive, and shut the dbs down if a user accidentally tries to run the network master copy.
 
Sharing a network copy with multiple people at the same time is a problem.
Before compacting on exit or other things listen to the experts on how to give each user a front-end each time they start the application and that will solve your problem.
1. Split the front-end from the back end.
2. Make your master (small compacted) copy that is the current version.
3. Look at the suggestion above, each user will download their own personal copy of the smaller DB to use for a session.
4. At the end of the user session, that user's copy is just deleted - Size doesn't matter

Stick with the advice of these experts. Many of us do exactly this and life is good in the Access universe. Doc and Gemma are pointing you in the right direction.
"The problem is that we believe we have time - Buddha"
 
You can also talk to your network admins about building a script that would copy the FE to the user's desktop when they boot (my SysAdmin Fu is old, but I think they can apply it for a specific Active Directory group). Have a directory on a server somewhere named \MasterCopy, when you make a new edition copy it there, and the next time the users start their computer they get a fresh, latest edition, version. And your master copy is backed up every night along with the rest of the server.

People running their own FE simplifies things greatly, and if one person's copy gets corrupted, just tell them to reboot their computer and they get a fresh copy.
 
You can also talk to your network admins about building a script that would copy the FE to the user's desktop when they boot

Windows Group Policies can have the paths to the source and destination in a policy and the domain controller manages the copy at the client logon or boot. The path supports environment variables so files can be very easily Created, Deleted or Updated from anywhere available on the network to anywhere on the domain client.
 

Users who are viewing this thread

Back
Top Bottom