MDA and MDW files

[mscertified]

Can someone explain to me what these files are and how they relate to MDB and
MDE files? We are going thru a major upgrade of Access 2.0 and 97 to 2000 and
have found many MDA files. We have no idea what these relate to. When a 97
MDB is concerted to 2000 are related MDA's also converted?

 

[Ed Robichaud]

MDA's were libraries (similar to DLL's) that were called and loaded into
memory when needed. As far as I know, they were for Access 2/97 and are not
used by any later versions.
-Ed

 

[GraemeR]

A *.MDA file is an MS Access add in. It's written in MS Access VBA. Once
upon a time (up to A97) you used them to extend functionality ib all areas
of MS Access design.
From A2K MDAs are used for the front end only, and COM Add-ins are used for
the backend. An MDA is an MDB file with a different extension.
If you don't use the add-ins then no problem. If you have the source code
then you can migrate them, but you'll need to test that all functionality
works. Alternatively obtain current version from supplier.

A *.MDW is a MS Access workgroup file. Again it's an mdb file with a
different extension. These are important if you have implemenbted secrurity
for your Access files. They're probably all called System.MDW and located in
the office installation or windows or system folder. You can't recreate a
user created mdw file without knowing the parameters used.so archive them -
search for "MS Access Workgroup Administrator" for more of a story on these
files. The workgroup administrator file is WRKGADM.EXE in the MS Office
installation folder.

HTH, Graeme.

 

[Larry Linson]

Can someone explain to me what these files are and how they relate to MDB and
MDE files? We are going thru a major upgrade of Access 2.0 and 97 to 2000 and
have found many MDA files. We have no idea what these relate to. When a 97
MDB is concerted to 2000 are related MDA's also converted?

MDA is a file extension used in Access 2.0 and earlier versions to identify
Access databases used for special purposes, such as "library" or "security
workgroup". The structure of those database was the same as the MDB file.
The default security workgroup file was named SYSTEM.MDA.

MDW is a file extension used in Access 95 and later for the "Security
Workgroup" database. The structure is the same as an MDB file, but the table
definitions and contents are used to implement Access security. The default
security workgroup file is now called (no surprise, I'll bet) System.MDW. A
"compiled" Access database is, by default, given an MDE file extension --
but the "compilation" is only a tokenization of the VBA code, not a real
compilation to machine language as you would find in recent versions of
classic VB or C or C++ or COBOL.

This is complicated by the fact that you can change the file extension
without changing the content of the file nor interfering with how it works.
Some do so to confuse people who are trying to break security -- it usually
doesn't work, but it often confuses whoever has to try to maintain the
database later.

Larry Linson
Microsoft Access MVP

 

[david epsom dot com dot au]

but the "compilation" is only a tokenization of the VBA code, not a real

:~) Well, not "tokenization": tokenisation is what interpreters did, to get
a more compact representation of the code.

Actually compilation, to a virtual machine, like the Java virtual machine or
the CLR virtual machine, rather than to the 'true' (separately virtualised
by both Windows and the processor) hardware machine.

A retrograde step in several ways - I don't accept that the nominal speed
advantage of VBA compilation outweighed the advantages of true
interpretation as seen in some earlier basics, or even the intermediate (p
code) compilation seen in Access 2.0 -- but that was the cost of using the
shared code base with VB5 and VB6.

(david)

 

[mscertified]

Thanks for the information.
Is there any programmatic way to determine if a MDB or MDE file is using a
custom workgroup file, or if an MDB or MDE uses add-ins? We have written a
program that opens every Access database on our servers and stores the Access
version. It would be nice if it could also flag databases which are protecred
by a workgroup file or which use add-ins .
David

 

[Immanuel Sibero]

Hi mscertified,

Is there any programmatic way to determine if a MDB or MDE file is using a
custom workgroup file, or if an MDB or MDE uses add-ins? We have written

a

A workgroup file is not used or tied to any particular MDB or MDE. An Access
session is.

In VB you can type:
? application.DBEngine.SystemDB
This will tell you what workgroup file is in use.

So... :
- Your mdb is not tied to or "using" any particular workgroup file. It's
using the workgroup file that your Access session is using.
- You specify a default workgroup file using wrkgrpadm.exe.
- You can override the default using command line parameter of msaccess.exe

version. It would be nice if it could also flag databases which are protecred
by a workgroup file or which use add-ins .

You can not examine an mdb or mde file and figure out what workgroup file
it's using. Workgroup file is tied to your Access session.


HTH,
Immanuel Sibero

 

[Larry Linson]

Is there any programmatic way to
determine if a MDB or MDE file is
using a custom workgroup file, or
if an MDB or MDE uses add-ins?

Immanuel addressed the first issue.

Other than examining the References, and knowing what libraries you identify
as add-ins, I don't know of a way to do the second. Perhaps someone more
versed on those "internals" can step in and explain.

Larry Linson
Microsoft Access MVP