access continues running until killed by tsk manager

[Guest]

Hi,

I run both office versions xp ( 2002) and 2003 with latest service Pack
applied on Windows Xp, using Oracle DB.
Occurrently quitting application does work to the point of leaving
application while access itself can't be closed. No error message appears -
it's just not closing. Only task manager helps.
I could reduce problem to have opened a few certain forms when access won't
close. Not opening these forms would do an ordinary close when ending the
application. I added a quit-procedure to menu for havin control right before
ending. Tried to find any suspicious open object - found nothing.
Does anybody know this problem ?
help would be appreciated

regards
gulli

 

[Scott McDaniel]

Hi,

I run both office versions xp ( 2002) and 2003 with latest service Pack
applied on Windows Xp, using Oracle DB.
Occurrently quitting application does work to the point of leaving
application while access itself can't be closed. No error message appears -
it's just not closing. Only task manager helps.

Have you tried a Compact and Repair? Make a backup of your file first, then do this.

If that doesn't work, try importing all your objects to a new, blank database.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Marshall Barton]

I run both office versions xp ( 2002) and 2003 with latest service Pack
applied on Windows Xp, using Oracle DB.
Occurrently quitting application does work to the point of leaving
application while access itself can't be closed. No error message appears -
it's just not closing. Only task manager helps.
I could reduce problem to have opened a few certain forms when access won't
close. Not opening these forms would do an ordinary close when ending the
application. I added a quit-procedure to menu for havin control right before
ending. Tried to find any suspicious open object - found nothing.

Most likely, you still have an open object or an object
variable that was never set to Nothing.

 

[Guest]

I have the same problem with Excel. I open Excel and close it right away. The
application exits, but the process only ends using task manager.
Any help on this would be appreciated.

 

[Marshall Barton]

I have the same problem with Excel. I open Excel and close it right away. The
application exits, but the process only ends using task manager.
Any help on this would be appreciated.

You'll probably get a better answer if you provide more
details about what you are doing, whats's in the workbook
and if you asked your question in an appropriate Excel
forum.

 

[Scott McDaniel]

I have the same problem with Excel. I open Excel and close it right away. The
application exits, but the process only ends using task manager.
Any help on this would be appreciated.

Is this something that occurs on several machines, or just one? If on several machines, and if you're having trouble
with both Access and Excel, then perhaps there's a problem with your Office installation. You can try to re-install
Office by re-running the installation and selecting the Repair option.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Guest]

Hi Scott,

thanks for quick response. Yes I did compact and repair. I also copied all
stuff into an new db without any change in behavior. I'm shure, there is
something left open. But how to find ? Is there a way to list all objects
used within application ? Searching in different forums I got the information
that a left open cloned recordset could produce this error. But it has been
acc97.
I'll try now to get a list of all open rs before leving.

thanks
Wilko

 

[Guest]

Hi Marsh,

thanks for quick response. Do you have an idea, how to get a list of all
open objects just before leaving application ? And another question : if a
form owns a recordset will it be closed when closing the form ?

regards
wilko

 

[Guest]

Gulli

Have you got any conditional formatting on forms? I had a similar problem
and found some references in the newsgroups that conditional formatting was a
potential cause. I removed them and the problem went.

Andy

 

[Marshall Barton]

You can check the db Recordsets collection for open
recordsets, but I don't think you can identify a dangling
TableDef, etc. Most of the time, the object rederence is in
a module variable and there is no way to iterate through all
variables.

Form recordsets are reliably destructed when the form
closes, but variables in the form's module (or any module)
might not be. I don't use ADO, but maybe you have an stray
connection running around somewhere???

I haven't experienced this problem in years, maybe because
MS fixed some/most of their object management code. More
likely because I suffered a couple of these problems and
became fanatical about closing everything I open and setting
everything to Nothing.

 

[Guest]

Hi Andy,

thanks for contributing new ideas. I have a problem to understand your
question. So I will shortly explain what I think is essential :
I have no bound fields on forms. Everything is read into recordsets ( by
oracle views ) and select criteria and then put into forms by procedures.
Formatting is done on treeviews - just text-concatenating and just a few date
formats ( yyyy.mm.dd ) at other places. We fill ListBoxes and DropDownboxes.
But as far as I know without special formatting. But perhaps you can explain
what formatting the reason has been in your case ?

regards
Wilko

 

[Guest]

Hi Marsh,

thank you for replies. I created a form to check for "left open" recordsets.
I can see a bunch of them and I can destroy them just before leaving
application. But that doesn't help. I don't use ADO. But I use Oracle
Dynasets in case of Updates. They can't be the reason becaus I didn't update
anything when testing.

But ist real that I can't find all the variables declared in specification
section of forms ? Sure I found no way, but I can't believe ..

It seems to be necessary scanning all the code ( and it is a huge work ) for
instanciated objects etc.

I will send information

regards
Wilko

You can check the db Recordsets collection for open
recordsets, but I don't think you can identify a dangling
TableDef, etc. Most of the time, the object rederence is in
a module variable and there is no way to iterate through all
variables.

Form recordsets are reliably destructed when the form
closes, but variables in the form's module (or any module)
might not be. I don't use ADO, but maybe you have an stray
connection running around somewhere???

I haven't experienced this problem in years, maybe because
MS fixed some/most of their object management code. More
likely because I suffered a couple of these problems and
became fanatical about closing everything I open and setting
everything to Nothing.
--
Marsh
MVP [MS Access]

thanks for quick response. Do you have an idea, how to get a list of all
open objects just before leaving application ? And another question : if a
form owns a recordset will it be closed when closing the form ?

 

[Guest]

Wilko

I experienced the problem of having to use Task Manager to stop a minimized
instance of Access (2000) after I had closed it. I searched through the
forums and checked out the suggestions offered. I then found this:-

http://www.thescripts.com/forum/thread189489.html

This rang a bell in my mind as a few days earlier I had added some colourful
Conditional Formatting to show a user that a sales offer was out of date. A
good description of Conditional Formatting is here:-

http://www.databasedev.co.uk/conditional_report_formatting.html

Forgive me if I'm simplifying things - I'm only a low level user.

I removed the formatting and it got rid of the problem.

It's worth noting that your problem might be due to how you reference a
Boolean control on a form - this in linked to in the first link at:-

http://www.mvps.org/access/bugs/bugs0005.htm

Hope this helps.


Andy

 

[Marshall Barton]

Well, you can write code that loops through all the
Form/Report/Modules and opens them in design view and then
parses out the declarations and builds a table of variables
and their containing module (see VBA Help for the properties
and methods of the Module object). But that would be a LOT
of work and even with all the names, you won't be able to
reference all the private variables. Your time would be
better spent reading your code and adding .Close and Set
=Nothing wherever they are missing.

One other thing that used(?) to cause this problem was using
a check box value in this specific way:
If Me.checkbox Then
The workaround was to do something to force it to use the
Value property. Any of these was sufficient
If Me.checkbox.Value Then
If Me.checkbox = True then
If (Me.checkbox) Then
But I thought this was fixed in A2002 or maybe A2003.

Beyond that, I really don't have a magic wand to ease all
the tedium of tracking it down.

 

[Scott McDaniel]

Hi Marsh,

thank you for replies. I created a form to check for "left open" recordsets.
I can see a bunch of them and I can destroy them just before leaving
application. But that doesn't help. I don't use ADO. But I use Oracle
Dynasets in case of Updates. They can't be the reason becaus I didn't update
anything when testing.

But ist real that I can't find all the variables declared in specification
section of forms ? Sure I found no way, but I can't believe ..

It seems to be necessary scanning all the code ( and it is a huge work ) for
instanciated objects etc.

You might be able to use something like Speed Ferrett or Rick Fisher's Find and Replace to go through your VBA code and
search for all instances of "As Recordset" or "As DAO.Recordset" or whatever syntax you use to declare your objects.
Short of that, I don't know of any method to locate all your Dimmed object variables ...



Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Guest]

Hi Scott,

thank you. I'll send information when I've done th job.

regards
Wilko

 

[Guest]

Hi Marsh,

I'll try to find something. Will send you information when I'm finished.

thanks and
regards
Wilko

Well, you can write code that loops through all the
Form/Report/Modules and opens them in design view and then
parses out the declarations and builds a table of variables
and their containing module (see VBA Help for the properties
and methods of the Module object). But that would be a LOT
of work and even with all the names, you won't be able to
reference all the private variables. Your time would be
better spent reading your code and adding .Close and Set
=Nothing wherever they are missing.

One other thing that used(?) to cause this problem was using
a check box value in this specific way:
If Me.checkbox Then
The workaround was to do something to force it to use the
Value property. Any of these was sufficient
If Me.checkbox.Value Then
If Me.checkbox = True then
If (Me.checkbox) Then
But I thought this was fixed in A2002 or maybe A2003.

Beyond that, I really don't have a magic wand to ease all
the tedium of tracking it down.
--
Marsh
MVP [MS Access]

thank you for replies. I created a form to check for "left open" recordsets.
I can see a bunch of them and I can destroy them just before leaving
application. But that doesn't help. I don't use ADO. But I use Oracle
Dynasets in case of Updates. They can't be the reason becaus I didn't update
anything when testing.

But ist real that I can't find all the variables declared in specification
section of forms ? Sure I found no way, but I can't believe ..

It seems to be necessary scanning all the code ( and it is a huge work ) for
instanciated objects etc.

 

[Aaron Kempf]

Access MDB is crap

move to SQL Server and Access Data Projects

seriously-- if i had a nickel for every MDB crash / hang that I'd ever seen?

I'd own Microsoft

 

[Aaron Kempf]

compact and repair is depecrated

move to ADP

File, New, Project (existing data)

 

[Guest]

hi folks,

I can't believe, I got it. as advised I debugged one form which I knew was
malfunctioning, stopped at certain points and tried leaving access. I could
find a public function used by different form coding to fill datavalues from
recordsetfield into formfield. For readability two objects have been set - a
form control and a recordsetfield. Value has been transferred by equalling
the object pointer :

set fd = rs.fields(i)
set c = fo.controls(fd.name)
if err = 0 then
c = fd
end if

I corrected to c.value = fd.value and everything goes.

Thanks to you all who gave help.

One question is still left - is there no way to scan form-variables
programmatically to get the names and put them into a list ? The only way I
know until now is opening the form_code modules and scanning the coded lines.
But I really don't like it this way.

nevertheless - thanks again to all you have been a great help

Wilko