.mde files

[Dave]

I am wondering about the Pro's and Con's of creating an .mde file from a
finished Access Project.
Obviously one of the Pro's is that it cannot be altered/edited/broken by the
users which is the main reason I want to consider this.
I also assume the application will be more stable and possible even run
faster in a multi user environment (4 or 5 users in this case).

One of my concerns is with future upgrades to the DB. I know I can save a
copy of the final .mdb, make changes there and recompile BUT what about
data? Is it retrievable, importable...How does the data in the .mde get
moved into the new .mdb before compiling (or can it)?
OR - are there any tools that can open, extract or change an .mde file back
to a .mdb file?

What other concerns or issues do I need to be awair of before taking this
step?

ALSO - as a side not I made a copy of my DB and tried going to
tools/Database Utilities/Make .mde file and got an error saying it can not
be done in Access 2000. However this DB was built using Access 2003. SO I
don't get what is up there.

Any help here will be appreciated.

Thanks in advance
D

 

[Guest]

First of all, you should split your database into frontend/backend. The
frontend (interface) will contain all your forms/reports/queries/modules etc,
the backend (database) will just contain your tables.

Once you have done this, you can convert your frontend to an .mde (always
keep a copy of your frontend .mdb for further development). You can keep the
backend as an .mdb.

The frontend .mde should be installed on each workstation. The backend .mdb
should be in a shared folder on your server/network.

When you do developments to your frontend, you just need to copy it to each
workstation. The backend will not be touched.

Look in Tools/Database Utilities. Do a backup before splitting (just in case).

If I understand you correctly, you are distributing the Access runtime?
If that is the case, your users do not need Access 2003 on their
workstations so would not be able to make any changes anyway. If you place
the backend .mdb on your server, it does not need either Access 2003 or the
runtime installed on it.

Steve

 

[tina]

ALSO - as a side not I made a copy of my DB and tried going to

tools/Database Utilities/Make .mde file and got an error saying it can not
be done in Access 2000. However this DB was built using Access 2003. SO I
don't get what is up there.

in order to make an MDE file, the database has to be in the same version as
the software you're using. though you can create an A2000 format db in A2003
(and in fact A2000 is the default file format in both A2002 and A2003), you
can only convert it to a .mdE file by using A2000 software. i'm not aware of
any work-arounds to that.

hth

 

[Dave]

Steve,
Great and clear reply. Thanks

I just tried splitting the db and is was painless.
however I do have a couple of questions.
- I just split the tables off. Then I converted my front end. I then opened
the front end and was pleased to see the I could not get to the forms design
however I could still f11 into the Object window and edit tables and
queries.
Is there a step I am missing?

- I am not sure what you mean by "distributing the Access runtime". I was
planning on having Access 2003 on the 4 workstations. IS this not
neccessary? Then what do I need on the workstations?

Thanks again for the reply - much easier then I expected.
D

 

[Dave]

Tina,

Thanks for the reply. I was unawair that the default format for A2003
was A2000.
Is there a way to change that?
Is there any real need to change that? (I mean the default format -
I have converted this current project to 2003)

Thanks
D

 

[Larry Linson]

I was unawair that the default format
for A2003 was A2000. Is there a way
to change that?

Yes, on the Database Window menu, Tools | Options | Advanced | Default File
Format.

Access 2003 Help, search on "file format" returns "Changing the default file
format" as the second topic. Access 2003 Help, while not nearly perfect,
has much improved content -- but it is "online primary," so works a lot
better if you have a high-speed Internet connection open.

Is there any real need to change that?

There are certainly some beneficial improvements between Access 2000 and
Access 2003, which will not work in an Access 2000 file format. One, for
example, was the addition of the OpenArgs property to Reports, for passing
data from the DoCmd.OpenReport to the Report itself. If you are satisfied
with the features/functions of Access 2000, there is no need to change.

Larry Linson
Microsoft Access MVP

 

[Dave]

Thanks Larry.
I will change the Default file format.
D

 

[Ron Hinds]

Steve,
Great and clear reply. Thanks

I just tried splitting the db and is was painless.
however I do have a couple of questions.
- I just split the tables off. Then I converted my front end. I then
opened the front end and was pleased to see the I could not get to the
forms design however I could still f11 into the Object window and edit
tables and queries.
Is there a step I am missing?

Before creating the .MDE, you need to go into Tools | Startup and uncheck
(at least) the checkboxes that read "Display Database Window", "Use Access
Special Keys", and "Allow Full Menus". I usually uncheck *all* of the
options here. You can also setup a Title for your application and even
choose an icon for it, as well as the default Form that will be displayed,
if you have one that acts as a "switchboard" or menu for opening your other
forms/reports.

- I am not sure what you mean by "distributing the Access runtime". I was
planning on having Access 2003 on the 4 workstations. IS this not
neccessary? Then what do I need on the workstations?

There is a (royalty-free) Runtime version of Access that is a limited
edition of the full version. You typically use it when distributing your app
to people outside of your own environment, where they may or may not have
the full-blown version of Access installed. This way, users of your app need
not also purchase the full version of Office. You'll find it on the Office
Professional CD in a folder called Runtime (IIRC), or just search for
accessrt* on the CD.

 

[Dave]

Yep - that solved my problem.
Thanks so much
D

Before creating the .MDE, you need to go into Tools | Startup and uncheck
(at least) the checkboxes that read "Display Database Window", "Use Access
Special Keys", and "Allow Full Menus". I usually uncheck *all* of the
options here. You can also setup a Title for your application and even
choose an icon for it, as well as the default Form that will be displayed,
if you have one that acts as a "switchboard" or menu for opening your
other forms/reports.


There is a (royalty-free) Runtime version of Access that is a limited
edition of the full version. You typically use it when distributing your
app to people outside of your own environment, where they may or may not
have the full-blown version of Access installed. This way, users of your
app need not also purchase the full version of Office. You'll find it on
the Office Professional CD in a folder called Runtime (IIRC), or just
search for accessrt* on the CD.

 

[Tony Toews [MVP]]

and possible even run
faster in a multi user environment (4 or 5 users in this case).

No, there is no appreciable performance difference in an MDE. Actually an MDB might
be slightly slower if the MDB needs some compiling but that should be quite
insignficant.

However there are some standard things you can do for performance.

The three most common performance problems in Access 2000 or newer are:
- LDB locking which a persistent recordset connection or an always open bound form
corrects (multiple users)
- sub datasheet Name property set to [Auto] should be [None]
- Track name AutoCorrect should be off

If the problem is for everyone when starting up the MDB then it likely needs a
decompile.

For more information on these, less likely causes, other tips and links to MS KB
articles visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/