@Colin,
I was unsure of whether the table in question is merely obsolete and hidden (or more than hidden, considering a thread not so long ago about really obscured objects) or whether it never exists in an ACCDB file. But my question is two-fold.
1. Why would the table still exist in an .ACCDB if it has "fallen off the grid"? Because Stefan's error says that table exists but is damaged. Otherwise, how would Access even know about it? Why would it CARE?
2. Why does Stefan get the error he gets and NOT either "No such table" or "No such field"? The error he gets strongly suggests that the table is still there but structurally not quite right.
@Stefan,
I now need to ask other questions as follow-up to your comment in your lead-off post:
The problem is in the GUI. Not sure why it occurs since i was only doing simple vba programming without touching the database.
WHAT were you doing in VBA? Is there a chance that this started when you tried to upgrade an existing .MDB front-end in-place? Or better yet, when did this problem first pop up? We need some history.
If Colin says MSysAccessObjects is no longer in use, I can understand that. And I begin to recall what those objects really were. They were the original "collections" that were the heart of the database: The Tables, Queries, Forms, Reports, Macros, and Modules collections.
When I looked at my old .MDB files again, I saw the ID values of the objects and they correspond to the "big 6" collections - the first things created in an empty database hence numbered objects 1 through 6 - which of course are no longer in use AS SUCH in .ACCDB files. (They exist now, but differently than they used to exist.)
So if you have an .ACCDB with that table in it, the question becomes "How did it get there?" An "upgrade-MDB-to-ACCDB-in-place" is one possible answer. I'm also wondering WHY the ACE engine would even CARE that such things existed since that table isn't used any more, or at least no longer has the same meaning.