Access Not closing (1 Viewer)

[Jon123]

Has anyone seem the problem when you close an access database and you think it is close but if you open the task manager you will see MSACCESS.EXE still running. Why ????

Jon

 

[Pat Hartman]

I've seen this problem reported before. You should be able to find the solution if you search but if I remember correctly, the problem is caused by leaving recordsets open. So, look at your code and any place you open a recordset, make sure you close it when you finish with it.

 

[ghudson]

I had that problem back when I tried to use the SendKeys function in Access 97. I quickly learned to avoid using any SendKeys functions ever since.

 

[Jon123]

Ok I figured it out but do not understand why it was doing it. I have a form that has a few field and command buttons kinda like a switch. When this form was opened at any point then when access would close MSACCESS.EXE was still running in task window. It did not matter if the form was still open or if it had been closed if it was opened at all. So what I had was a field which pulled a Date from a pm table. Then I had a second field that had this code in the control "=DateAdd("m",+6,[PM Date])" This would add 6 months to the 1st field and worked fine until you close the dbase and access staied running. Now I moved the code from the control and put it in the default valve of the field and everything work fine now. So my question is why?

Jon

 

[Truth_Luvver]

We had this problem. Turned out that - in our case - it was because we were opening a new MS Access app (App #2) from within a form's "On Load" event, and then also, closing the current MS Access app (App#1) using docmd.quit.

This managed to open App#2 but left it invisible. App#1 closed up and was gone from view. However, there would be at least one or more MSACCESS.EXE processes running still. The only way to close App#2 was to kill those processes, then open App#2 and close it.

This is how we fixed it:

[SIZE=1]' INSIDE THE ONLOAD EVENT, WE HAVE THIS CODE:[/SIZE]
[SIZE=1]' open the other Access app, App#2, from within App#1. appAccessToBeOpened.OpenCurrentDatabase publicPathAndFilenameOf2003Version[/SIZE]
 
[SIZE=1]' explicitly direct that App#2 be made visible (previously it would open as invisible)[/SIZE]
[SIZE=1]appAccessToBeOpened.Visible = True[/SIZE]
 
[SIZE=1]' now start to close the app we are inside of, App#1[/SIZE]
[SIZE=1]Application.CloseCurrentDatabase[/SIZE]
 
[SIZE=1]' Exit this sub, the On Load event, and then the On Unload Event will be kicked off[/SIZE]
[SIZE=1]Exit Sub[/SIZE]

Inside the Unload Event for this form...

[COLOR=#1f497d][COLOR=#1f497d][SIZE=1]Private Sub Form_Unload(Cancel As Integer)[/SIZE][/COLOR]
 
[COLOR=#1f497d][SIZE=1]    '  this is where the quit can work successful to quit the app.[/SIZE][/COLOR]
[COLOR=#1f497d][SIZE=1]    Application.Quit[/SIZE][/COLOR]
 
[COLOR=#1f497d][SIZE=1]End Sub[/SIZE][/COLOR]
[/COLOR]

(Note, I would have posted a link to the other thread where I posted this, however, we are not allowed to post links in this forum until after reaching 10 posts; and I just signed up today.)

- Sandi Sawyerr
w w w . LadySword . com

 

[gemma-the-husky]

a similar common cause is also that a recordset has been opened, and not disposed of.

 

[ChrisO]

Dave.

>common cause< It can not be said to be a “common cause” because there has never been even a single case proved. What has been happening is that, over the years, the same old reasons have been given but never any reproducible proof.

I think you will find that the problem can not be reproduced by failing to close a recordset. It can be reproduced by the inappropriate use of the Application.Quit command. There may be other ways to cause the problem but, despite what we read, a failure to close a recordset is not one of them.

No one will supply a sample containing reproducible proof of the “common cause”, no one.

Chris.

 

[RainLover]

a similar common cause is also that a recordset has been opened, and not disposed of.

I have spent quite some time testing for this fault.

I have never been able to reproduce it and neither has anyone else as far as I know.

I have posted sample code that demonstrates a through testing which never fails.

I could point to it as I posted it in the archives.

If you can post any sort of proof that the unclosed recordset does as you claim then that would be good to see.

 

[gemma-the-husky]

Hmm

recordset issue

I always thought this was an issue, but I just tried a couple of ways and couldn't reproduce it. Maybe I was wrong, maybe it was version dependent (A97 maybe), or maybe MS fixed it in an update at sometime.

Thanks for the feedback.

 

[RainLover]

This was a falsehood from the beginning.

I have had this independently tested on Access Version 2.00. I think that was a windows for workgroups product.

No problem found.

 

[ChrisO]

Dave.

It’s good that you finally got around to running some tests on this matter. What you erroneously believed to be correct has been around for many many years.

In post #2 (dated 2005) Pat made the same claim but it has been claimed on the www for much longer than that.

The version 2 tests RainLover was referring to were performed by Wayne Phillips of Everything Access.Com. I’m not sure which year he did those Version 2 tests for us but it was about 2008.

The real point about all of this is that some people do test these things but most don’t.
The results of the tests (the result of all that work, a lot of work) can be nullified by a single post which might simply rely on scaremongering.

Unless we have first hand knowledge of a specific subject I think it would be better not to make claims about things we can’t prove.

Chris.

 

[gemma-the-husky]

thanks Chris

I must say I was really surprised when I tested again and found I could not reproduce the issue. I will investigate some old databases. It would be nice to clarify the real cause.

 

[ChrisO]

>>I will investigate some old databases. It would be nice to clarify the real cause.<<

Absolutely the correct thing to do: And if you do find one you will be the first to do so.

If you, or anyone else, would like to test it, the VBA DoCmd.Quit command can produce some strange results. If you do a search on Google you will find that very few people know anything about it. One of the most damaging things it does is to Reset global variables without warning and before VBA code stopes running.

It’s that very Reset of a global pointer to a Recordset, along with bad error handling, which can put Access into an error loop and that can prevent Access from closing.

There is a demo attached and it has nothing to do with failing to close a recordset.

Chris.

 

[gemma-the-husky]

thanks for that, Chris - maybe that was the cause of the apparent recordset issue - that is the type of behaviour I recollect.

I recall some other interesting contributions you have made about public variables losing context. I know you are always very precise in your statements.