Solved Gracefully quit Access (1 Viewer)

[mib1019]

Hi,

I have a button on a Dashboard form to close Access. May have several objects open in the database, so want to close the program 'gently'. Current Database properties include Compact On Close. What would you suggest?

Thanks!
MIB1019

 

[Isaac]

Hmm. The way this would work for me is, I'd have pretty much the whole database interface managed by a Tab control on a main underlying form. In the rare event other forms need to pop up for dialogues, they always open modally, so they have to be closed before the user can interact again with the "main" form (with its tab control holding all pages & forms), and then there is an Exit Database button on that single form, so I can just Application.Quit from there.

Hopefully the only "several objects" that you allow your user-facing program to have open are Forms or Reports ... and never in design view. Couldn't you just use Application.Quit? Or is it because you are worried they are in the middle of editing a record and might run into your BeforeUpdate validation code?

I guess what I am saying is under normal circumstances, and all else being equal, you can simply use Application.Quit even if forms are open. You do not need special code to check if forms are open, etc.

I would recommend you not use Compact on Close. It is notorious for causing problems. And given a proper split database configuration, there is normally little to no worry about your users' front ends bloating in size.

 

[Micron]

If you need to worry about it, you could loop over the db forms collection, checking the IsLoaded property and don't invoke the Quit method if the function returns True. Just closing the application will close all open forms; however, if any have unfinished records, those records will be saved if Access allows it for those forms. If not, you'll likely raise errors.

 

[missinglinq]

Building on @pisorsisaac@gmail.co's comment:

http://rogersaccessblog.blogspot.co.uk/2010/12/should-i-use-compact-on-close-feature.html

Pay particular attention to Roger's fourth point!

Paradoxically, as he pointed out, compacting is a recognized cause of corruption and should only be done after making and safely storing a backup copy of the database.

Linq ;0)>

 

[onur_can]

After disabling the Close button in your form's design mode, add a button to your form and type the following line in the Click event. This is the most safe and gentle method of exit from MS Access.

Application.Quit

 

[mib1019]

Thank you all! I will turn off Compact on close and keep an eye on it for bloat. I assume I need to turn it off on the two files, front-end and back-end.

You're all the best!!
MIB1019

 

[Isaac]

Thank you all! I will turn off Compact on close and keep an eye on it for bloat. I assume I need to turn it off on the two files, front-end and back-end.

You're all the best!!
MIB1019

I can't remember ever being asked about compact on close for a back end, but I'm not sure why - it's a legit question. I guess I'd turn it off for both, if it were me, and handle the occasional back end Compact as an item of manual maintenance. Unless you want to get fancy at some point and set up some kind of scheduled automation, but yes the FE shouldn't really experience much bloat if any, since you're not storing any data there. You manually compact the FE each time prior to deploying a new version

 

[Micron]

You could set a parameter for a max file size and only compact if it gets there. I'd have the code perform a be backup first, and probably just over-write the last one.
EDIT - my comment applies to the be, not the fe, which typically should not experience much bloat.