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:3sj0201f7c7jdl7gn2ehcc62d9cmt8fgjq@4ax.com...[color=blue]
> We were testing a version of our app that's been running for months with[/color]
no[color=blue]
> 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[/color]
them[color=blue]
> on my developer box: no problems. In each of those two cases, the PC's[/color]
were[color=blue]
> connected to the same test server and *supposedly* had the same production[/color]
build[color=blue]
> image on them.
>
> One more puzzler: it's going out the window on a subform's Form_Current()[/color]
event[color=blue]
> and dying on a line that Dims a field. I've never seen this before -[/color]
seems like[color=blue]
> 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[/color]
Dims...at[color=blue]
> the beginning of the routine, before anything else happens.
>
> One last thing: even though the offending form/subform are closed and[/color]
nothing[color=blue]
> should be going on in the app, it keeps on throwing "Object no longer[/color]
exists"[color=blue]
> messages - but this time they aren't trapped by the app's code and they[/color]
just[color=blue]
> keep stacking up in the app's window over top of the "Home" form. It's[/color]
like MS[color=blue]
> Access is in some kind of loop.
>
> Anybody seen anything like this? Print drivers? Service packs? Cosmic
> radiation?
> --
> PeteCresswell[/color]
