Access keeps running after I close it...

[Michel S.]

Hi !

In an Access application, if a given form is used, Access doesn't
terminate normally (ie: I have to Ctrl-Alt-Del and kill Access in the
process list before being able to reopen the .MDB again)

I have checked that all objects created in every step, function or sub
called in this form are set to nothing in their "terminate" event.

Despite this, the problem remains..

I do not have a boolean control I test without an equal sign (ie: "If
chkPrinter Then" instead of "If chkPrinter = True Then" ), even if I
think this bug applies only to Access 97.

I'm using Access 2002, sp3.

Any other things to check for ?

Thanks

 

[google-post]

Often this means that you didn't close an object.

For instance, if you have the following in a subroutine:

set MyDB=currentdb
set MyRST = MyDB.openrecordset("Select * from MyTable")

....you should also have:

MyRST.close
set MyRST=nothing
MyDB.close
set MyDB=nothing

before exiting the subroutine.

Often, I'll simply have a defined exit point...for instance...

ExitHere:
if not MyRst is nothing then
MyRST.close
set MyRST=nothing
end if
....etc.

John

 

[Bill Mosca]

Michel

Are you sure there are no error traps that are bypassing your set blah =
Nothing?

I always do the set to nothing line in my error trapping at the exit label
as in:

exit_Routine:
Set blah = Nothing
Exit Sub

err_Routine:
msgbox "Bug here."
Resume exit_Routine
End Sub

Try setting your code options to break on all errors to see if anything pops
up.

 

[Michel S.]

(e-mail address removed) a formulé ce jeudi :

Often this means that you didn't close an object.

For instance, if you have the following in a subroutine:

set MyDB=currentdb
set MyRST = MyDB.openrecordset("Select * from MyTable")

...you should also have:

MyRST.close
set MyRST=nothing
MyDB.close
set MyDB=nothing

before exiting the subroutine.

Often, I'll simply have a defined exit point...for instance...

ExitHere:
if not MyRst is nothing then
MyRST.close
set MyRST=nothing
end if
...etc.

John

Thans for your reply.

AFAIK, every objetc created is closet and set to nothing.

But can this happen if I use directly an object like in :
set rst.open = "Select ..... ", CurrentProject.Connection, ...

Does this "CurrentProject.Connection" may be the culprit ?

 

[Bill Mosca]

Does this "CurrentProject.Connection" may be the culprit ?
No, that shouldn't be a problem since you did not set it. Its scope is
limited only to as long as the recordset is open.

 

[Michel S.]

Thanks for your reply, Bill.


Actually, I set a breakpoint a *each* End Sub / End Function of all
called modules (standard or class) to check the state of the
variables/objects used by the modules. I verified that all objects
are set to nothing upon exciting.

I only use "On Error Resume Next" form of error trapping when things
can go wild, and the corresponding "On Error Goto 0" is very close. I
don't think this could cause the problem I'm experiencing.

Michel


Bill Mosca a exprimé avec précision :

 

[Pieter Wijnen]

you should not close currentdb

ie
set db = currentdb
db.close ' plays havoc
set db = nothing

this does not apply to other opened db's though (and isn't harmful in '97)


--
Pieter Wijnen

My feeble Access pages (good links though)
http://www.thuleeng.com/access
When all else fail try:
http://www.mvps.org/access
http://www.granite.ab.ca/
http://allenbrowne.com/
http://www.lebans.com/

 

[Dirk Goldgar]

"Pieter Wijnen"
<it.isi.llegal.to.send.unsollicited.mail.wijnen.nospam.please@online.rep
lace.with.norway>
wrote in message news:uyb%[email protected]

you should not close currentdb

ie
set db = currentdb
db.close ' plays havoc
set db = nothing

this does not apply to other opened db's though (and isn't harmful in
'97)

In current versions of Access, closing database objects set from
CurrentDb doesn't do any harm (though I agree it's a bad practice), but
it doesn't do any good, either. The Close method is just ignored. In
older versions it could cause problems, but I'm not sure when the fix
was put in.

A good rule of thumb is, "If you didn't open it, don't close it."

 

[Bill Mosca]

On error resume next could very well be a problem. It should only be used
when you are absolutely sure of all possible errors that could occur in a
routine. And because it fails silently, no one will ever know it failed.

I still think you should set you break on all errors option until you find
the cause.

 

[Terry Kreft]

Michel,
You have to identify the bare minimum steps to recreate the problem.
Once you've identified that then it brings the problem space down
dramatically.

Say you identify that it's enough to open and close the form to recreate the
problem then you are looking at
The code which opens the form
The code in the form which runs when it opens
The code in the form when it closes
The code which runs after the form closes

This would normally be a lot less code to step through than the whole of the
code behind the form.

 

[Michel S.]

Bill,

As I said, I only use error trapping around statements which are error
prone and disable it as soon as I can like in :

On Error Resume Next
cnn.Open
blnErr = (err.Number <> 0)
On Error GoTo 0

If blnErr then.... ' here I don't care of what the error was; just
want to know the connection failed.

This should not left many doors opened for unclosed objects..

Michel

Bill Mosca vient de nous annoncer :

 

[Michel S.]

Thanks Terry,

Actually, I'm using my own switchboard to open and close forms.

Since the problem occurs only when this specific form is used, I doubt
the problem lies within the form open/form close code.

That's why I'm investigating the code behind form only..

Michel


Terry Kreft a exposé le 2006-08-18 :

 

[Terry Kreft]

I was merely giving an example, the principle of finding the minimum number
of steps to re-create the problem still applies. If you find them then the
problem is much reduced.

 

[Michel S.]

Thanks for your input again..

I just explained why I was putting my efforts in the CBF instead of the
other events..

It's a form containing subforms which in turn open class objects.

I checked all "terminate" events of class objects to make sure
everything I created was closed and set to nothing, idem for the form
and subform Unload and Close events..

But so far, I didn't found anything wrong, but MSASSESS process is
still running upon closing this application.

Michel


Le 2006-08-18, Terry Kreft a supposé :

 

[Terry Kreft]

You don't seem to be reading what I am writing, so I'll just drop out now.

No need to respond.

 

[Keith H.]

Michel, if conditional formatting is involved in this problem, you may
want to try this out:
http://database.ittoolbox.com/groups/technical-functional/access-l/database-quit-488212#

I had a similar problem recently, and this worked for me...

Good luck!

 

[Michel S.]

Terry,

No need to be rude because english isn't my usual language.

I have read your reply about reducing the steps required to find the
problem and confirmed that it was I did.

I explained that I reduced the steps to recreate the problem as you
sugested, but at no avail..

I'm sure the problem is occuring only with one form, not any other.

Even opening the form without using my switchborad causes the problem..
Thats eliminate all code which opens / close the forms.

Ab¸nd I think this complies with the "minimum steps" you are
suggesting...

If this doesn't meet what you were saying, I'm sorry because that's
what I understood. If this is something else, fell free to explain it
further.

Michel



Terry Kreft a pensé très fort :

 

[Bill Mosca]

I don't see where anyone mentioned closing. The question concerned setting
objects to Nothing.