Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Access 2000, intermittent run-time Error '2467'

Status
Not open for further replies.

wrs3

Programmer
Mar 3, 2001
5
US
Run time error '2467' (reference to an object that is closed or doesn't exist) is intermittently raised (but always at the same VBA procedure line) when referencing a control (setting its .Enabled property to False).

This code is in a standard module and is successfully used repeatedly in the application for many forms. Some forms never have raised the error, yet execute this same procedure.

Two forms (at this point anyway) raise it at times, and at other times, work correctly. I can see no distinctive pattern, timing, or other factor that would cause this to happen.

Thanks.

 
More input to describe the problem: The intermittent failure occurs---when it does---only in explicit Item(index) style references to (in this case) the Controls collection, not apparently when the control is referenced within a "For Each" style context.

Again, this is intermittent, and the indexes appear valid.

It is almost as if the Access Application believes the control is missing from the collection (yet it is there), or if the explicit index itself is being interpreted inaccurately.

Thanks.
 
Is this standard module executing in the same process and thread as the form? Or is it some kind of background ActiveX process? The reason I'm asking is that, if you happened to be indexing the Controls collection while its constituent controls were being rearranged, there could well be a brief moment during which a given control is not in the collection--yet by the time you looked at it with Debug or Locals, it's been reinserted in its new location, looking like it was there all along.

Other than that, is there code in your application that's dynamically creating and destroying controls on forms? This would change the contents of the Controls collection and shares the issues of the preceding paragraph, though one would think in this case there would be better synchronization. Rick Sprague
 
Reply to Rick. Good thought, but no it is executing as part of the standard environment, and I am not adding/removing controls---at least not knowingly.

My work-around (which is ugly) has been to use the "For Each" mechanism to access the controls on the forms and essentially rebuild the collection as an array of control objects, and then index through this, as before.

The intermittent nature of this is troubling, and while the work-around seems to be getting me past the problem, I have no illusions that it won't re-surface. Consequently, I would still look forward to help on its solution or other instances where a similar problem has been encountered so perhaps some pattern or underlying root-cause can be isolated.

Thanks.
 
This is going to seem somewhat off the track but it has happend to me. Access will raise an error totaly unrelated to the actual cause. The problem I was having was a recordset object was not closed properly and Access would totaly skip over an unrelated section of code (even in break mode!) After I found the problem with the recordset the other problem has never come up again. My 2 cents would be to look around for some other process that may be different with respect to the forms that seem to work.
John A. Gilman
gms@uslink.net
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top