By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,647 Members | 1,706 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,647 IT Pros & Developers. It's quick & easy.

"Object No Longer Exists" error on one machine, but not another?

P: n/a
We were testing a version of our app that's been running for months with no
problems and it started throwing "Object no longer exists" messages on two
machines in the test environment.

We tried the same test scenario on a production box: no problems. Tried them
on my developer box: no problems. In each of those two cases, the PC's were
connected to the same test server and *supposedly* had the same production build
image on them.

One more puzzler: it's going out the window on a subform's Form_Current() event
and dying on a line that Dims a field. I've never seen this before - seems like
if something's having trouble with a Dim it's going do happen at compile
time....but this is consistantly happening at a line of code that just Dims...at
the beginning of the routine, before anything else happens.

One last thing: even though the offending form/subform are closed and nothing
should be going on in the app, it keeps on throwing "Object no longer exists"
messages - but this time they aren't trapped by the app's code and they just
keep stacking up in the app's window over top of the "Home" form. It's like MS
Access is in some kind of loop.

Anybody seen anything like this? Print drivers? Service packs? Cosmic
radiation?
--
PeteCresswell
Nov 12 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Pete, not sure I can help, but these ideas come to mind.

What changed recently on these 2 machines? New code? Different service
packs? Windows patches? Other software installed? Logical disk problem
(chkdsk/scandisk)? Not enough free disk space? Excessive CPU usage? Faulty
network?

What differences are there between these 2 machines and the ones where the
probem does not exist? Get the FullPath of each Reference, and check the
version of each one. Make sure there are no duplicate DLLs elsewhere on path
or in the "current" folders. This link is useful for programmatically
returns the versions:
http://www.mvps.org/access/api/api0065.htm

Once you have eliminated interference from the hardware, network, o/s, other
software, Office installation, and dll-hell, you are down to looking at your
own database. Presumably you have already tried the obvious such compacting,
creating a new database, turning off Name AutoCorrect, turning off
unnecessary references, and then importing the objects from your problem
database.

Does the problem occur only after running something else? For example, if
you close the default workspace (typically after executing a DAO
transaction), Access transparently reopens it, but any secondary Databases
that were open are not automatically reopened. Since the RecordsetClone of
forms is opened in secondary Databases, referring to the form's
RecordsetClone fails with Error 91 ("Object no longer Set") until you close
the form and reopen it.

It would be helpful to know *what* object no longer exists. Are you able to
get to the Immediate window when this happens? Can you get a basic reference
from the top of each library's tree, e.g.:
? Access.acViewPreview
? VBA.vbYes
? DAO.dbEngine.DefaultType

If they all work, see if you can get information on the type of object that
it is trying to Dim. It may fail on the Dim line simply because it is the
first line in the proc, or Dim could fail if the call to assign memory did
not work.

The endless loop thing could be a clue. There are several scenarios that can
trigger this. Triple-check the Form_Current event is not dirtying something.
(Amazing how often people do that.) Same for Form_AfterUpdate or
Form_AfterInsert. Is is possible that your Form_Current code is triggering a
change that could cause Access to be reloading the subform? Any calculated
fields could also set up loops - especially if they are any way involved in
the link between main form and subform. Remove any conditional formatting on
the form, since that can generate endless loop.

Not sure that's wonderfully helpful, Pete, but hope there is something of
use there.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"(Pete Cresswell)" <x@y.z> wrote in message
news:3s********************************@4ax.com...
We were testing a version of our app that's been running for months with no problems and it started throwing "Object no longer exists" messages on two
machines in the test environment.

We tried the same test scenario on a production box: no problems. Tried them on my developer box: no problems. In each of those two cases, the PC's were connected to the same test server and *supposedly* had the same production build image on them.

One more puzzler: it's going out the window on a subform's Form_Current() event and dying on a line that Dims a field. I've never seen this before - seems like if something's having trouble with a Dim it's going do happen at compile
time....but this is consistantly happening at a line of code that just Dims...at the beginning of the routine, before anything else happens.

One last thing: even though the offending form/subform are closed and nothing should be going on in the app, it keeps on throwing "Object no longer exists" messages - but this time they aren't trapped by the app's code and they just keep stacking up in the app's window over top of the "Home" form. It's like MS Access is in some kind of loop.

Anybody seen anything like this? Print drivers? Service packs? Cosmic
radiation?
--
PeteCresswell

Nov 12 '05 #2

P: n/a
RE/
Does the problem occur only after running something else? For example, if
you close the default workspace (typically after executing a DAO


It's occurring after a rather lengthy series of table updates wrapped in a DAO
transaction.

Moving back a little from the immediate symptom, it seems like the recordset
behind a subform is going "Poof!". If I can get inbetween the repeated
"Object..." errors and force a change of the subform's .Recordsource to
something else and then back to it's original source that's enough to stop
further errors from popping - and the subform is then populated normally.
--
PeteCresswell
Nov 12 '05 #3

P: n/a
Good. That's narrowed it down.

Instead of executing a transaction on the default workspace, try
CreateWorkspace and Append it. The transaction there should be independent
of the default workspace.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"(Pete Cresswell)" <x@y.z> wrote in message
news:10********************************@4ax.com...
RE/
Does the problem occur only after running something else? For example, if
you close the default workspace (typically after executing a DAO
It's occurring after a rather lengthy series of table updates wrapped in a

DAO transaction.

Moving back a little from the immediate symptom, it seems like the recordset behind a subform is going "Poof!". If I can get inbetween the repeated
"Object..." errors and force a change of the subform's .Recordsource to
something else and then back to it's original source that's enough to stop
further errors from popping - and the subform is then populated normally.
--
PeteCresswell

Nov 12 '05 #4

P: n/a
RE/
Good


But if it works, I'm still left with the question: why on machine and not on
another.... But I guess I'm getting 'way ahead of myself.......
--
PeteCresswell
Nov 12 '05 #5

P: n/a
> But if it works, I'm still left with the question: why on machine and not on
another.... But I guess I'm getting 'way ahead of myself.......


Turns out that if we install Jet service pack 8 on the problem
machines, the error doesn't happen anymore.

All corporate builds should already have this service pack in them, so
the current theory is that something in the build process downlevels
something. Machines in the production environment, which have had
various updates pushed down to them do not have the problem - only
test machines with a virgin build.
Nov 12 '05 #6

P: n/a
Pete, thanks for posting the fix.
Another one goes down to service packs.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"PeteCresswell" <Go**********@FatBelly.com> wrote in message
news:74**************************@posting.google.c om...
But if it works, I'm still left with the question: why on machine and not on another.... But I guess I'm getting 'way ahead of myself.......


Turns out that if we install Jet service pack 8 on the problem
machines, the error doesn't happen anymore.

All corporate builds should already have this service pack in them, so
the current theory is that something in the build process downlevels
something. Machines in the production environment, which have had
various updates pushed down to them do not have the problem - only
test machines with a virgin build.

Nov 12 '05 #7

P: n/a
RE/
Pete, thanks for posting the fix.
Another one goes down to service packs.


It's not over yet.

We now how to fix it, but not how it got that way - although I'm going to guess
it turns out to be something very parochial...not very interesting to the rest
of the world.
--
PeteCresswell
Nov 12 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.