Is there a wrong way to close MS Access? (1 Viewer)

[nbowman56]

Hi all,

I have a coworker that went around informing everybody yesterday that using the top right red x to close Access does not actually fully close it. They said you have to go through File -> close for it to be properly closed.
Now, I've never heard of such a thing, and this coworker, despite his computer science background, has been known to make things up. I've been looking online and have found nothing that indicates that this theory is correct.
What do you all think?
Thanks,
Nicole

 

[theDBguy]

Hi Nicole. As far as I know, the red X quits the Access application, and the File > Close menu only quits the opened database but keeps the Access application open. However, I can't verify this at the moment because I'm not in front of a computer.
Sent from phone...

 

[nbowman56]

Thank you for the fast response! It looks like you're correct. I don't understand why this coworker is thinking such a thing, but I wanted to be absolutely sure before informing my other colleagues that he is incorrect (especially because I just started this job). He believes the database will still be in the background processes in the task manager if using the red x to close, but this doesn't seem to occur when I tested this out. We have a problem with people opening from the shared network despite telling them to put the front end on their desktop and not closing the databases so then others can't get in. He thought the problem could be because they were closing access incorrectly and they weren't actually out of Access when they thought they were. I told my supervisor I'd investigate so here I am - if anybody else has heard anything on this topic, please reply! But it seems that you (theDBguy) are quite knowledgable about Access so good to know that you use the red x to close out of Access.

 

[pbaldy]

I agree with theDBguy, and it's easy enough to check via Task Manager to prove him wrong. Many of us use utilities of some sort that manage copying the version from the server to the local machine. I hide the server copy so nobody can open it directly.

 

[theDBguy]

Hi. In addition to what Paul said, you can also place a code in the startup routine of the database to check if the user is starting it out on a network or local drive. If on a network drive, you can display a warning message and quit the application. That should prevent them from not running it on their local machine.

 

[MajP]

So, the good news I could have done it wrong 10s of thousands of times, and nothing has happened yet. Fingers crossed.

 

[moke123]

We have a problem with people opening from the shared network

Add a procedure that checks for the file location and if its in the shared folder quit access.

 

[Micron]

There is an answer to the question posed by your thread title and it is 'yes'. Terminating with task manager, shutting down Windows with the db still open, pulling the plug.... any of which are likely to corrupt data if not the whole db.

 

[isladogs]

Agree with all previous answers.

Another perfectly good way of closing your database is using the code Application.Quit e.g. On a button click

 

[nbowman56]

Wow thank you all, what a cool forum! I'm feeling much more confident in saying that he's wrong.
We actually have code set up in a couple of our main Access databases to check whether they are opening from their own drive, so I will make it my priority to incorporate this into all of the other databases (and we have a ton).
I will inform the misinformed managers that the red x is A-Okay.

 

[theDBguy]

Wow thank you all, what a cool forum! I'm feeling much more confident in saying that he's wrong.
We actually have code set up in a couple of our main Access databases to check whether they are opening from their own drive, so I will make it my priority to incorporate this into all of the other databases (and we have a ton).
I will inform the misinformed managers that the red x is A-Okay.

Hi Nicole. Good luck!

 

[Micron]

I wonder what that person uses to close Word or Excel? If there's one thing that M$ values among Office apps it's consistency, so why would Access be any different? That being said, you should consider if clicking the application close button can result in half-finished data entry or issues when a query takes a long time to run. I think so many people who are faced with such queries (as an example) try to do something else in the db and get some sort of "not responding" message which makes them think it's hung up when it's not. They give it the 3 finger salute (force a close) and wonder why data is corrupt. So you might want to suggest removing the app close button to prevent that possibility, but you can also use that suggestion as a way to placate those who believe the other guy.

I'm feeling much more confident in saying that he's wrong.

If you're the new kid on the block, I'd suggest being diplomatic about it.

 

[nbowman56]

Micron, haha don't worry, I am a very diplomatic person and my statement was much more blunt then I'd actually go about. I don't intend on just calling him out, I just may discuss it with him.
Yes, thank you for bringing the force close potentially corrupting data to my attention. I will make sure to investigate that further and bring that up when I discuss this with my colleagues and supervisor.

 

[Pat Hartman]

When Access is "busy", the X in the upper right isn't active. That is when people resort to the three-finger-salute or the even more draconian, power off button. Power off, reboot, Cancel with task manager ALL can corrupt data and so users need to be warned against using them.

For your part, if you have any long running processes, put up a form where you can show status or at least warn the user that he should be patient and go get a coffee. If it's still not done, call you.

 

[sonic8]

He believes the database will still be in the background processes in the task manager if using the red x to close, but this doesn't seem to occur when I tested this out.

This might actually happen. It might be caused by either code in your Access application or in add-ins not properly releasing references to database queries/connections.
If this is the case, it should not make a difference how you close the application. However, I can imagine that closing the database first before closing Access might slightly reduce the possibility of that problem happening.

So, while in general I agree with everyone here that it should not make a difference how you close Access, your coworker's idea might be based on his own correct observations.

 

[The_Doc_Man]

Let me approach this from another angle.

I had a database that included tests for incomplete operations on each form that could do any updating, inserting, or deleting (which was about 80% of what I did). If you had STARTED to update something or enter something through a non-passive form, the form was "dirty" and my rule was "You can't leave your dirty stuff out." So I implemented a trapper that would block closing the form while dirty.

I of course had to test it. The upper-right X on the dirty form was blocked by my code. So was the File>>Exit operation. I had a "control panel" or "dispatcher" form that controlled things. The control panel's upper-right X (which would normally close the app) was also blocked. The Close App button on the switchboard was blocked. The working forms couldn't close the app so that wasn't a needed test. The Access window's upper-right X was blocked. They all counted as leading to form closure more or less the same way through more or fewer steps to the same point.

The only ways that the app could be closed without forcing cleanup is repeated use of Alt-F4 (one time wouldn't do it); or clicking the lower-right Windows icon and doing a software shutdown (and giving it permission to terminate the blocking app); or pulling the wall plug. (Well, actually the battery unit's plug...) ANY of those methods risked damage to the file. However, the other items I listed in the previous paragraph could be blocked by a single piece of code (in the form's OnUnload event, which has a Cancel option) and would prevent damage.

Now, here's the straight skivvy from the operating system standpoint. There is NO DIFFERENCE to the app between File>>Exit or App Window's corner X because NEITHER ONE manipulates anything that is currently open within the app. If a form is open and busy, the ONLY correct way is to finish the form's actions and close it before you close the app. Failing to do this will potentially have negative side effects on the DB but depending on what the form was doing, it might make NO difference or it might totally invalidate the database or it could be something in between.

 

[The_Doc_Man]

I see that Pat and Sonic8 also posted. One last warning... IF this app happens to open another App (we call this "using an application object"), it is POSSIBLE that closing Access will leave the other app still open. Excel is notorious for this with Word a close second. This doesn't affect Access but does affect the other app, particularly if IT had something open at the time.

 

[nbowman56]

Thank you all for the additional information.

So I just discussed this with the coworker, and he will be showing me if his observation occurs again (finding Access in the background process despite being closed). I told him that I believe him, as I've seen it happen, but I don't believe it's because of using the red x. After some prodding, he did tell me that it happens exclusively during crashes of the database. I had told him that this had happened to me today (Access appeared closed but was in the background processes), but it was due to attempting to open an already known corrupted file. So that's now my top theory for when this happens, the file is already corrupt in some way, and that's when it doesn't shut down properly. I did let him know that I agreed with him that not closing out forms appropriately could potentially hurt the database/data in some way so I may look more into how we can ensure that these forms are closed.

The_Doc_Man - I like your idea, and may try to incorporate this somehow as I am looking to optimize these databases in any way possible. Dirty data tends to be an issue here, and we would like to reign this in somehow. I'd love to take a look at your code for this if possible, or if you could point me in the right direction, that would be great.

 

[The_Doc_Man]

Sadly, I don't have sample code for this because the major DB project where I most recently did this and the one before it were the property of the U.S. Navy (where I worked) so there was no such thing as taking a copy home with me. It wasn't classified but the Navy was a stickler for regulations and it meant I couldn't keep samples.

Tell you what... read up on the Form_Unload event, which fires BEFORE the Form_Close event. The Unload event has an input parameter called Cancel which is passed in by reference. If you are not ready to let go yet, return a value of -1 (or acTrue) to that variable. Since it is By Reference, you can affect the value of the caller (which is Access). That will cause the form to stay open. I.e. it cancels the Unload event. If the form can't unload, it can't reach the Close event.

So... how do you decide to do that Cancel step? It requires a rather tedious setup but once you've done it a few times, it isn't hard at all. I used the control's _LostFocus events for any bound fields on my forms. If the control had changed, the _LostFocus code would set a flag in the form's declaration area. If even one bound field changed, this flag would be true. There ARE other ways to do this but I needed the flag for initial debugging and just never changed the method later. Then in the form's AfterUpdate event, if no errors had occurred I would clear the flag. And the Form_Unload event would test that flag to see if it was OK to close or not.

When using this technique, I always included a message-box in modal dialog mode when that special flag said "NO" because that stopped just about everything. You HAD to acknowledge that modal dialog and it told you the form was dirty.

 

[gemma-the-husky]

USING NETWORK COPY

You may have already had some info about this. I put code in my startup procedure to check the drive letter that's being used (currentproject.path). If it's greater than say "G", I warn the user they can't use the network copy, and quit the database.