Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Access stays in Task Manager even after I close it

Status
Not open for further replies.

LifeDragon

Programmer
Jul 12, 2005
6
CA
Hello,

I have a a slight problem when I close Access.

Some times when I quit the application, it's closes and all, but there's a MSACCESS.EXE program still running in the Task Manager which means it's still running.
And as long as it runs, I can't open Access again until I go kill the process manually.

To my knowledge, it's probably because Access could not close a reference to a certain object in my database, but I'm not sure of it.

So all I'd like to know if there is a way to flush Access Memory before closing so that it won't stay in the computer memory. Or any other way to make sure nothing stays in memory.

Thanks
 
As far as I know, which isn't necessarily that far under such conditions, as I've never encountered it, you can't do such "wholesale" (except, possibly using the End statement, BUT that wouldn't be curing anything, just addressing the symptoms of the memory leak, not the cause).

In theory, Access is supposed to release all objects when leaving a routine, but experience has thought us better;-)

I'll make it a rule to always explicitly close all objects that I've opened (recordsets, connections...), then release them all explicitly too, through set myobject = nothing.

Note - if you have two objects, where one is dependent on the other, you may end up in such havoc by trying to close/release in the wrong order. Sometimes a strategic DoEvents may give the system enough time to properly close/release objects before doing the next...

Also, a possible culprit - lot of us use errorhandling along the lines of this simplified stuff

[tt]on error goto myerr

' lot of useful code, instantiating and opening stuff
' using numerous libraries...

' properly releasing the objects

myexit:
exit sub/function
myerr:
' do some reporting/logging of the error
resume myexit
end sub/function[/tt]

Now - what happens if an error occurs in the middle of all the usefull stuff?

It jumps directly to the errorhandler without doing the proper close/release

Using ADO, I find myself often doing something like this in the exit part, if I've opened a recordset for updating...

[tt]myexit
if (not (rs is nothing)) then
if (rs.state = adstateopen) then
if (rs.editmode <> adeditnone) then
rs.cancelupdate
end if
rs.close
end if
set rs = nothing
end if[/tt]

Roy-Vidar
 
I see,
I tried doing that recently, since I can't clear them all in one shot, but I think I missed some recordsets [tongue]

I guess I'll go explore my code again to find all the recordsets I could possibly have opened [smile]

Thanks a lot

A small question by the way,
Is the Rs.Close necessary, if I already have "Set Rs = Nothing"?
Because if it is, I just found out my problem and how to solve it [tongue]
 
I'm sure I've seen somewhere in the help files claiming setting a DAO recordset to nothing effectively also closes it, but do I trust it...

In most cases the claim is correct, but in some cases, under some conditions, not doing both can cause memory leaks.

But by all means, there are lot of other possible culprits for memory leaks too, see for instance what faeryfyrre found out here thread705-617643 (note also pseales comments). Also, do follow the link at the end of the thread, for another possible culprit (incorrect reference to form control in a controlsource).

Not directly related, but a discussion mentioning the need to "clean up", can be found here thread705-723340.

Roy-Vidar
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top