mde, mdw, mdb - How are they known to one another?

[Shakaz99]

Hello,

This set of questions may seem odd, but please bear with me. Due to
downsizing, I have inherited a group of Access applications. I am not an
Access programmer (yet).

I work build backend/frontend bits in other languages, so I am familiar with
data construction, code and presentation. I can muddle through the Access
equivalents.

My problem is that I am lost in the file structure. I understand that when
you split a database you end up with an mdb file which does not contain UI
ojbects, an mde file which is a compile version of the UI and an mdw file
which holds the security bits.

What I don't understand is how they all know about each other. The
shortcuts point to the mdw file. I assume the mdw file must know where the
mde file is and the mde file knows where the mdb file is. I just do not see
how they do it.

The development folders I have inherited sometimes match the production
folders in basic structure and sometimes do not. So it does not appear to be
a case of sticking files in a similar structure and everyone is happy.

I have scanned search engines and am about to go get another book but, if
someone could enlighten me (or point me to an article) on how all the file
bits know the location of their counterparts, I would greatly appreciate it.

Thanks in advance. Appologies if this questions seems odd or convoluted.

 

[Douglas J. Steele]

As you state, you need to start the front-end file (the mde from your
description) with a shortcut that points to the mdw file. (You can define an
mdw file as being the default, but that's seldom recommended)

Within the front-end, you should have linked tables defined that point to
the actual source of the tables. (Each table has a Connect property that
points to the source)

 

[Shakaz99]

Thank you very much.

Then, if I understand correctly, the mde and mdw must reside in the same
startup folder so they can find each other?

 

[John W. Vinson]

Then, if I understand correctly, the mde and mdw must reside in the same
startup folder so they can find each other?

That is not in fact essential: you can use a shortcut such as

"%PROGRAMFILES%\OFFICE11\MSACCESS.EXE" "H:\Consulting\SPCALA\Current\sp.mdb"
/wrkgrp "F:\General\sp.mdw"

If you don't specify the /wrkgrp optional operand, Access will indeed look in
the same directory as the frontend database.

Note that the frontend will (for the user) normally be a .mde but it can also
be a .mdb; the developer will need to use a .mdb in order to make design
changes to the application, and create a new .mde for distribution.

 

[Douglas J. Steele]

John, I'm not quite sure what you mean by

If you don't specify the /wrkgrp optional operand, Access will indeed look
in
the same directory as the frontend database.

I thought that if you don't specify the /wrkgrp operand, unless you've
specified a different standard security file, Access looks for system.mdw,
which is typically in C:\Windows\System32. Is this different than your
experience?

 

[John W. Vinson]

I thought that if you don't specify the /wrkgrp operand, unless you've
specified a different standard security file, Access looks for system.mdw,
which is typically in C:\Windows\System32. Is this different than your
experience?

Nope... brainfade on my part. You're quite correct of course! Thanks Douglas!

 

[David W. Fenton]

What I don't understand is how they all know about each other.
The shortcuts point to the mdw file. I assume the mdw file must
know where the mde file is and the mde file knows where the mdb
file is. I just do not see how they do it.

When you execute the shorcut, you are passing a commandline argument
to the MS Access executable that tells *is* what workgroup file has
the users and groups that apply to the file you're opening. Access
takes care of managing all of this. If you provide the wrong
workgroup file, it won't match the security information stored in
the objects in your front end, and it won't run.

It is the Access process (actually, Access delegates all of this to
the Jet database engine) that manages all the information.

 

[Rick Brandt]

Hello,

This set of questions may seem odd, but please bear with me. Due to
downsizing, I have inherited a group of Access applications. I am not
an Access programmer (yet).

I work build backend/frontend bits in other languages, so I am familiar
with data construction, code and presentation. I can muddle through the
Access equivalents.

My problem is that I am lost in the file structure. I understand that
when you split a database you end up with an mdb file which does not
contain UI ojbects, an mde file which is a compile version of the UI and
an mdw file which holds the security bits.

What I don't understand is how they all know about each other. The
shortcuts point to the mdw file. I assume the mdw file must know where
the mde file is and the mde file knows where the mdb file is. I just do
not see how they do it.

The development folders I have inherited sometimes match the production
folders in basic structure and sometimes do not. So it does not appear
to be a case of sticking files in a similar structure and everyone is
happy.

I have scanned search engines and am about to go get another book but,
if someone could enlighten me (or point me to an article) on how all the
file bits know the location of their counterparts, I would greatly
appreciate it.

Thanks in advance. Appologies if this questions seems odd or
convoluted.

The front end "knows" about the back end because the location of the back
end is stored as part of each link's definition. The back end has no
knowledge of the front end.

The relationship between the MDW and the others is not as "hard" as most
people think. Here is an analogy...

There is a mall with five entrances. At each entrance you are handed a
colored card. Within the mall are various establishments and each one
requires that you present a card of the proper color to get in.

The establishments have no idea which mall entrance gives out the card
they accept and the guys handing out cards at each entrance have no idea
what establishment the card they hand out is good for. The only thing
that matters is that the doorman at the establishment determines that you
are in possession of the correct card.

That is how MDWs work. You start an Access session with a given MDW and
establish within that MDW who you are and what groups you belong to.
Afterwards, the opening of a particular Access file is attempted and that
file decides if who you are and/or the groups you belong to give you the
right to open the file. The MDW does not care what MDB/MDE you might try
to open and the MDB/MDE don't care which MDW file you used. Only that
your ID or the ID of the groups you belong to are sufficient to let you
in.

Now, it might be true that there is exactly one MDW file that contains
users and/or groups to allow access to a particular MDB/MDE file, but
that is coincidental and not because of any "link" that the files have
with each other.

 

[Shakaz99]

Thank you all for your replies. I am beginning to get less of the "deer in
the headlights" feeling.

I have a couple other related questions, if you do not mind:

1) If I try to open an mdb file using the "Open" command from the "Office"
button the starting form of the app shows briefly and then the application
closes. Is this because I am not referencing an mdw file and it knows
security has been set up? I would think it would simply ask me for the
admin password.

2) I can open one of the databases using a shortcut which points to the mdb
file, a wrkgrp switch and a path to the mdw file (see shortcut below).
Everything looks fine. Tables, forms, security is all there. If I try to
relink a table (e.g. AreaTrain table) and choose to "prompt new location' and
point it to the mdb file which is explicitly listed in the shortcut, I get an
error which says: "The Microsoft Office Access database engine cannot find
the input table or query 'AreaTrain'. Make sure it exists and that its name
is spelled correctly." However, if I ask to relink AreaTrain and do not
prompt for a new location, it runs fine. I believe I am pointing to the same
place. I am just concerned that if I release the code into the wild and try
to relink tables, since I will have to pick a new location, that I may have
problems. Does that make sense?

Thanks again for your patience and wisdom... Kim.


Shortcut:
"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE"
"D:\DOCS\Teamskills\Edson Test of 2007 KCK\Data\TeamSkills.mdb" /wrkgrp
"D:\DOCS\Teamskills\Edson Test of 2007 KCK\Program\EdsonSystem.mdw"

 

[John W. Vinson]

Thank you all for your replies. I am beginning to get less of the "deer in
the headlights" feeling.

I have a couple other related questions, if you do not mind:

1) If I try to open an mdb file using the "Open" command from the "Office"
button the starting form of the app shows briefly and then the application
closes. Is this because I am not referencing an mdw file and it knows
security has been set up? I would think it would simply ask me for the
admin password.

It would, or would simply open with no objects visible. My guess is that your
database has a Form specified as the startup form, or an Autoexec macro which
runs code that closes the database. Try holding down the Shift key as you open
it.

2) I can open one of the databases using a shortcut which points to the mdb
file, a wrkgrp switch and a path to the mdw file (see shortcut below).
Everything looks fine. Tables, forms, security is all there. If I try to
relink a table (e.g. AreaTrain table) and choose to "prompt new location' and
point it to the mdb file which is explicitly listed in the shortcut, I get an
error which says: "The Microsoft Office Access database engine cannot find
the input table or query 'AreaTrain'. Make sure it exists and that its name
is spelled correctly." However, if I ask to relink AreaTrain and do not
prompt for a new location, it runs fine. I believe I am pointing to the same
place. I am just concerned that if I release the code into the wild and try
to relink tables, since I will have to pick a new location, that I may have
problems. Does that make sense?

Thanks again for your patience and wisdom... Kim.


Shortcut:
"C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE"
"D:\DOCS\Teamskills\Edson Test of 2007 KCK\Data\TeamSkills.mdb" /wrkgrp
"D:\DOCS\Teamskills\Edson Test of 2007 KCK\Program\EdsonSystem.mdw"

Are you looking in TeamSkills.mdb for the tables? If so, they aren't there!
That's the frontend which should have only links to the tables. You can't tell
from the shortcut where the backend, with the tables, actually resides. If you
open the frontend (bypassing the Startup form if necessary) and look at the
tables window, you can hover the mouse over a table name and see its Connect
string, or view the Connect string using code as discussed elsewhere in the
thread. THAT is the backend where the tables are.