A couple of things spring to mind. If you have a lot of linked tables, this can cause this problem. Check your code and see if you are repeatedly opening recordsets - if yes, try to circumvent the need for those sets.
My thought is that the error has little or nothing to do with the error message. I have gotten several messages from Access that don't exactly describe the true problem. I can't imagine that you are actually opening that many database objects at once. Have you tried the easy stuff? Repairing the database? Compacting the database? If you have, I might suggest importing all your objects into a blank database. That is what I used to do with a 97 database that suddenly started getting obsucre errors.
Make sure you make a copy of the database first before you try repairing.
My thought is that the error has little or nothing to do with the error message.
How true that is, especially with Access 97.
In addition to DCKunkle's suggestions, pursue /Decompile command line switch. Also, it may have to do with quantity of code. I started getting "Out Of Memory" errors when opening a Form or Query on a rather larger project built in Acc97. My platform has 1GB of RAM and an 80 GB HD, so I dobt I was actually running low on memory. Turns out that Acc97 uses Jet's resources to store compiled code and as I was happily developing away, I was starving Jet. The fix was to decompile, then compile, then compact AND to sneak in the registry and up Jet's allotted memory (there's an MSDN article on this, I'd don't have the link handy )
There's multiple threads in this forum on decompile, memory, mysterious errors, etc.
Thanks TC, actually I decomp/compile very regularly, plus compact etc, all of which helps to prevent Access getting it's knickers in a knot, esp in larger projects. Sometimes I find that Access corrupts objects, esp forms and reports, and then I rebuild the db - ie, create a new db and import all objects. This works 99% of the time.
My US associate tackled MS about this, and I thought everyone might like to see their response:
-- quote --
Access will allow you to have 255 table ids open at the same time. For instance if you run a query based upon five tables you will have five table idsopen. If you open five forms based upon the same query you will have 25 table ids.
There is not any way to get an accurate count of how tableIDs you have opened. Combo-boxes, list boxes, complex queries, code, numerous tables, system tables, etc. all contribute to the maximum number of TableIDs. For each of these objects, there may be more than one TableID created, so there is really no way of determining the number used. For instance if you run a query based upon five tables you will have five TableIDs open. If you open five forms based upon the same query you will have 25 table IDs. If the forms have combo boxes and list boxes, Dlookup statements, etc., you can see how you would eventually get to the error by exceeding the amount of TableIDs that can be accessed, but it would take a lot of objects which are tied to a lot of tables or queries to reproduce the error
A TableID is a recordset pointer that the database engine uses, and is not exposed to the user. The Jet database engine may open multiple TableIDs during the execution of a single query; however, there is no accurate method to estimate the number of TableIDs that the Jet database engine will use for any given operation.
If you have any code attempting to open multiple databases in the same workspace by way of a global variable, change the code to use procedure-level variables to initialize database variables when possible and eliminate the recursive variable declaration. When you split your database and link the tables in the background Jet will be creating at least 2 additional queries for each linked table to fetch the data. This approach would cause you to run out of available tableids more quickly than having all tables local. Hope this helps to clarify the behavior customer is seeing. Please let me know if you have any additional questions.
-- end quote --