Hi Jack,
I have only 15 attached tables so it doesn't seem like that would be a
problem.
While you may have only 15 attached tables, how many other objects (queries,
forms, reports, macros, and modules) do you have, and how many controls do
you have on your forms and reports? Do you have any forms and reports with
empty modules (ie. the HasModule property is set to Yes, but it could be set
to No)?
Create a brand new database and immediately disable the NameAutocorrupt
feature (see:
http://allenbrowne.com/bug-03.html for reasons why you want to
do this). Then import all objects from the source database into the new
database, one group at a time. In other words, import all tables (but not
linked tables), then import all queries, then all forms, etc. While Access
will allow you to import all objects in one operation, the experts at FMS,
Inc. (a Microsoft Partner), have stated that it is best to import objects one
group at a time.
Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html
Recreate any linked tables from scratch. Access can cache a lot of
information about linked tables, which may no longer be valid, so it's always
best to recreate the linked tables from scratch. When importing any local
tables, make sure to check the option to import relationships, menus and
toolbars, and import/export specs. If any of the local tables in the source
DB are hidden, you'll need to first unhide them. You will need to set the
checked references to match the source database, along with any startup
options set under Tools > Startup. Going through this process often times
solves corruption problems, because you get a new set of the hidden system
tables (the tables whose names start with "MSYS"). These system tables are
updated appropriately as you import objects.
This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group at a
time, re-establishing any linked tables, setting startup options, and setting
references to match the source DB is usually a fairly quick procedure. When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.
You might also want to first verify that you really need all checked
references in the source database. It is not unusual to find all kinds of
extra references checked that are not required. If your code compiles okay
without a checked reference, then you didn't need it in the first place. My
advice is to only include a reference if it is needed.
After rebuilding your database see if you can create a .mde file successfully.
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
:
The calander OCX was definetly the problem. Now I am receiving an error that
says:
This error is usually associated with compiling a large database into an MDE
file. Due to the method used to compile the database, a considerable number
of TableID references are created for each table. The Microsoft Jet database
engine version 4.0 can only create a maximum of 2048 open TableIDs at one
time. Exporting a database as an MDE potentially can exceed this limit if
the database has a large number of objects (table, macro, form, report, etc).
There is no accurate method to estimate the number of TableIDs the Jet
database engine uses during the process of compiling a database as an MDE.
However, each VBA module and each form uses one TableID, as a result, if the
database has 500 forms, and each form's HasModule property is set to Yes, as
many as 1,000 TableIDs are used.
I have only 15 attached tables so it doesn't seem like that would be a
problem.
__________________________________________
:
PS. I forgot to mention that you might want to use Allen Browne's calendar
form, in place of the ActiveX based calendar that you are currently using.
Popup Calendar
http://allenbrowne.com/ser-51.html
This will allow you to run without the calendar OCX file (remove any checked
reference as well). For example, your problem might be caused by item #16 in
the Can't Make MDE listing. With Allen's calendar, this would be a non-issue.
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
:
Hi Jack,
Check out this list:
Cannot make .MDE
http://www.access.qbuilt.com/html/conversion.html#CannotMakeMDE
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
:
I am trying to make on MDE on an application MDB with forms and queries and
attached tables. I also have a form that has a calendar OCX file. When I go
to Tools->Database Utilities->Make MDE... the program hangs up. What could
be causing this. I have save my files as formats 2002 - 2003.
