I'm trying to make a database that I
created executable on any machine. I
thought I could do this by making it an
.mde file but that doesn't work for
some reason.
There is no way to create an executable from an Access database. If you have
the Office Developer's Edition for your version of Access (A97 - A2002), you
can package your database with runtime support so it can be used on machines
where Access itself is not installed. The runtime support for Access 2003 is
included in a separate product, Visual Studio Tools for Office 2003 System.
None of these alter your MDB or MDE in any way -- they just package with the
runtime in an installable package.
See below for discussion of MDE -- it is not represented to be "executable"
in any Access documentation of which I am aware.
Also I noticed that file extension after
I emailed it was .ldb What is file exten-
sion is .ldb & what is a .mde file used
for exactly if it doesn't work in this matter?
An .LDB file records the users active in the database of the same name at
the time. This is particularly useful (internally to Access, you don't do
anything with it directly) when you have applied Access security -- that may
be why some call it the "Lock Database". If there is not a .LDB file, one
will be created when the first user logs in to the database. It _should_ be
deleted when the last user logs out, but there are some circumstances where
this does not happen.
An MDE is a "compiled" Access database file -- that shouldn't be confused
with "compiled" as in "compiled C code". When you create an Access MDE, the
VBA code in modules in your database is stripped of comments, different (and
generally unintelligible) references replace your readable variable names,
and the text you see in VBA statements is "tokenized" into codes that can be
more quickly interpreted by the Access software. Forms and Reports are
"locked" so they cannot be opened in Design View, because Forms and Reports
can have modules attached.
Creating an MDE makes it difficult for someone to steal your database and
code and alter it, but is not foolproof. However, the caveat is that most
Access applications are sufficiently simple that an experienced Access
developer can see the application run and re-created it in just a fraction
of the time it took to create it initially. Still, used in conjunction with
Access security, it is as good a barrier as we can throw up to protect our
applications.
Larry Linson
Microsoft Access MVP
