Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
Solved

Access 2003 DB Compile Fails On Too Many table Ids

Posted on 2014-04-27
10
540 Views
Last Modified: 2014-04-28
Hi Experts,
I have a large MS Access 2003 MDB.  The one MDB contains multiple distinct Modules each of which has its own Main Menu form.
In trying to compile it into a MDE it fails on too many open TableIDs for the MS Jet DB Engine V4.0.

What is the best method to overcome this problem?  With each Module being quite distinct I could put each Module in a separate MDB / MDE and open them from a MDB / MDE containing the Application Main Menu.  If so what code do I use to start them up?

Is there a better way to overcome this problem?

Thanks.
Bob Collison.
0
Comment
Question by:Bob_Collison
  • 5
  • 2
  • 2
  • +1
10 Comments
 
LVL 27

Expert Comment

by:MacroShadow
ID: 40026137
Before attempting to create an MDE compile the code from the Visual Basic Editor (Debug->Compile), this error may mean that you have compile error(s) in your code, once corrected you should be able to create the MDE.

It may also be caused by corruption, try doing a Compact and Repair (Database Utilities->Tools).

If none of the above suggestions work, create a new db and import all objects from the original file.
0
 

Author Comment

by:Bob_Collison
ID: 40026224
Hi Marco,
Normally I do a Debug > Compile and cleanup any issues before doing a Compact / Repair followed by a Make MDE but in this case I missed doing it.  There was a compile error which I fixed and it created the MDE.

However, I do have a large number of Tables, Reports, Forms with a lot of development still to go so I may yet run  into this problem.  Therefore I would still like to know what my options are especially for running each Module as a separate MDE from a Common Module in MS Access.

Suggestions?

Thanks.
Bob Collison.
0
 
LVL 27

Accepted Solution

by:
MacroShadow earned 500 total points
ID: 40026235
Not a good idea! You won't run into this error because you have to many objects in your db.
0
Ransomware: The New Cyber Threat & How to Stop It

This infographic explains ransomware, type of malware that blocks access to your files or your systems and holds them hostage until a ransom is paid. It also examines the different types of ransomware and explains what you can do to thwart this sinister online threat.  

 
LVL 40
ID: 40026238
What do you mean when you say that each module has its "Main Menu form". A module does not have such thing as a menu or a form, it's only a container for code.
0
 

Author Closing Comment

by:Bob_Collison
ID: 40026240
Thanks for the solution and information regarding too many Objects.
0
 

Author Comment

by:Bob_Collison
ID: 40026324
Hi James,

The whole Application has 10 Application Modules based on 'Subjects'  e.g.  Member Module, Finance Module, Event Module, etc. based on Subject DB Design (as opposed to Application DB Design.  Each of these has a Form Object that provides access to and control of that Module.  In addition there is an overall Application Menu Form Object from which the Application Module Menus are run.  Although there is some Common Tables for lookups etc. (e.g. Address Master based on relational concepts) most of the data relating to a Subject is controlled within that module.  Each Module has its own Back End DB for its data.  This allows Users to have multiple copies of each Module DB.  A Utility provides for the rapid switching / linking from one Module DB copy to another.

Thanks.
Bob Collison.
0
 
LVL 57
ID: 40026926
Bob,

Couple of comments to add in:

1. I would have tried using /decompile, just to make sure everything was good.
2. I would have gone through the DB and ensured that any form which had no code had it's "HasModule" property set to false.
3. If this was on the 64 bit edition of Office.   The 32 bit edition doesn't seem to have as many issues.

Jim.
0
 

Author Comment

by:Bob_Collison
ID: 40027104
Hi Jim,
Thanks for the comments I'll keep them in mind for the future.  Normally as I complete each bit of development I save it, Compact / Repair and then Compile.  If it compiles I keep a copy of the Source as a backup in case I run into issues.  If it doesn't compile I debug it or if necessary revert to the backup and start over (doesn't happen often).

I am developing on a 64 Bit Windows 7 Pro PC with Office 2010 Pro installed except for MS Access.  The MS Access that I am using / developing in is Office 2003 Pro and for installations I provide the MDE Version along with MS Access 2003 Pro Runtime via InstallShield.

Before releasing the code I use FMS Total Access Analyser to review all errors / suggestions at which time I ensure that the HasModule property is set correctly for each form.

Thanks again.
Bob Collison
0
 
LVL 57
ID: 40027163
On the /decompile, that's something that is a little different.  If you've "compiled", the VBA project carries two copies of the code; source and a partial compile (VBA only does an incremental compile, not a full compile in the usual sense of the word).

Sometimes due to corruption or Access bugs, the compiled version gets out of sync with the source.  As a result, you may not be able to generate a MDE even though your code compiles fine.  

 The inability to produce a MDE almost always deals with code because a MDE is nothing more than a MDB with the source code stripped out.

You can either use /decompile (and for details, see here: http://www.experts-exchange.com/Database/MS_Access/A_2043-Decompile-What-it-is-what-it-does-and-how-to-use-it.html ) or import everything in a new DB container (only source code is copied when you do this).

That may or may not fix the issue, but often does.

Having a valid value for has module will reduce the number of table ID's required when creating a MDE and may get you past the limit, which is 2048.  That varies a bit though as it's not a hard and fast limit, which brings up another point; when you go to create the MDE, make sure you do so after just opening Access.  That way, nothing else is in memory at the time.

That can manage to eek out a few more table ID's on the limit.

Jim.
0
 

Author Comment

by:Bob_Collison
ID: 40027213
Hi Jim,
Thanks very much for the insights.  I'll use them in the future.
Thanks again.
Bob Collison.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I see at least one EE question a week that pertains to using temporary tables in MS Access.  But surprisingly, I was unable to find a single article devoted solely to this topic. I don’t intend to describe all of the uses of temporary tables in t…
Preparing an email is something we should all take special care with – especially when the email is for somebody you may not know very well. The pressures of everyday working life stacked with a hectic office environment can make this a real challen…
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

790 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question