stephen

I have been trying to debug a MS Access 2002 DB that has the folowing issue:

When a user quits the application, the MSACCESS.EXE process remains open
(shows up in the task manager processes) and prevents them from properly
re-opening the database. In fact, they often get the Access Program icon in
their control bar at the bottom of the screen, however they cannot close
it...the application appears to be in "limbo" where a specifc MDB is not
open, but the user canot open a new MDB or close the application. I am not
sure why this process remains active when they exited the database, and
often times, the user will end up having multiple MSACCESS.EXE processes
open.

I have tried multiple message boards and here is what I have done so far
(but these dont seem to have worked)

1. I change the application exit to "application.quit" from "docmd.exit".
This didn't help
2. I have gone through every line of VB code to find when the DAO database
object is opened (set db = currentdb) and added a "db.close" line after the
"db.execute.." code to make sure it closed the connection immediately after
executing the SQL line (i.e INSERT, DELETE, etc.)
3. I have gone through every line of VB code to find when the DAO recordset
is opened (set rs = db.openrecordset...) and added a "set rs = nothing" line
after the recordset is finished

The odd thing is that the problem occurs almost immediately in the program.

I tried the following:
1. Opened the program to the default "opening form" screen and then exited
the database. There was NOT a residual MSACCESS.EXE in the task manager.
2. Opened the program to the default "opening form" screen and then went the
first navigational screen (frmClients). I stepped through the VB code as it
processed the code and it never actually opened either a recordset or db
connection. However, when I close the form and then exit the database,
there IS a residual MSACCESS.EXE in the task manager.

So I cannot determine why these residual processes are not being closed.
Are there any other known causes of why multiple occurances of the MSACCESS
process resides in the task manager?

What is the difference betwen doing a "db.close" and a "set db = nothing"
command? When would I decide to user each of them?

Help?

exited the database. There was NOT an residual MSACCESS.EXE in the task
manager.

tony toews

<snip>


There are some other causes of this problem as well. Involving form
check boxes. See Access minimizes to Windows 95/NT toolbar instead
of closing http://www.mvps.org/access/bugs/bugs0005.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

albert d. kallal

Actually, you got the above backwards. The suggestion to fix this problem is
to CLOSE all reocredsets, and then set all reocrdssets = nothing. Usually
this fixes the problem. In reading the above, you did not close your
reocrdsets when done. You some how got this mixed up..and are closing the db
refs..but not the reocrdsets!

In fact, the use of db.close, and setting db = nothing will not generally
fix this type of problem.

In fact, I would NOT execute the db.close all over the place...as it is not
needed, and could actually be source of problems! (why try and close the
current db ref?..it don't make sense to do that!).

So, for any reocrdset that you open, you want:

rstMyRecordSet.Close
set rstMyrecordSet = nothing

You likely don't have to worry about, or bother with the database ref "db".


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
pleasenonoSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn

albert d. kallal

Hum, no. As mentioned, I have *usually* seen this problem when you declare
global reocrdsets in a standard module...and don't close them. If you have
any other kind of objects that are GLOBAL, then I would also check that
code. So, does that form use, or deal with any kind of global vars? (we
talking about any kind of object here...and not just recordsets). Further,
does the form use any special controls beyond a standard text box?


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
pleasenonoSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn