Joan,

Many thanks for coming back to me so quickly, and please accept my apologies
for my delay in replying to your reply.

Firstly, I'm sorry, but I don't quite understand what you mean by "security
groups" in your second post - I've been developing my Access skills over the
last 12 months, but I've only had the need (aka courage) to dip into security
over the last week or two, so some of the terminology has still to embed
itself in my head (aka block of wood!).8=)

Secondly, reading your first post, I think that my inexperience may have led
me to incorrectly describe my problem, so what follows is an attempt to put
it in a more logical way - I do desperately need your help, so I hope this
helps you to help me. (This may take quite a while for me to write, because
I'm still not sure that I understand the why's and wherefore's of Access
security, but what the hey!). It is also highly likely that the problems that
I am envisaging and the threads of logic I have used to envisage them are
entirely flawed, but again, I'm hoping that if I am on totally the wrong
page, that you'll give me a quick kick in pants and set me right.

Although the first implementation of the system I have written is for a
school only 300 yards away (and which I can visit at the drop of a hat), I
hope to be able to present it to many other schools around the area or even
further afield where it won't be possible for me to do the installation
myself. I envisaged therefore to be able to send it out on a CD as an ADE
packaged solution that would work whatever their configuration (naive I know,
but I live in hope).

So the idea would be that the user would first install the package on their
fileserver which would comprise both BE and MDW (so that all clients use the
same MDW). They would then install the FE on each client PC. In order to
allow the FE to fireup, (most likely on a machine that had no Access
installed), I thought that I could also get them to put a (temporary) copy of
the MDW on the client PC. Call the fileserver MDW as MDWServer, and the
client one as MDWClient.

The user would load fire up the client based FE which would immediately see
the MDWClient and using a "limited access" login ID I provide, and get
through to a configuration form. On this form, I have placed a toolbar with
the Workgroup Administrator icon. By pressing this, the user can than join to
the MDWServer (wherever it may be, e.g T:\My Documents, or V:\Programs, etc).

I therefore didn't want to force the ADE package to automatically configure
the desktop shortcut to use the MDWClient as it would always use this
whenever the user double-clicked the shortcut - thereby ignoring the contents
of the MDWServer.

I tried this out on a PC without Access installed at it seemed to work fine,
but when I loaded the package on a PC that had Access, and fired it up it
didn't work. The system started without any request for a logon ID, and then
proceeded to tell me that I didn't have permission to run the initial
configuration form. Needless to say, I couldn't go any further.

My assumption from this was that the system recognised the presence of a
standard system.mdw and attempted to use the Admin user of that MDW to grant
access to my application, thereby completely ignoring the presence of my
MDWClient.

As I said above, it is highly likely that I still don't understand the
complexities of the way mdb/mde files interact with mdw files and that my
logic is wrong, but I would like to be able to provide something to the users
that a) is as simple as possible to implement, b) user a single MDW, and c)
can work in a fileserver environment with client PC's that may or may not
have Access.

Again, I've probably rambled on for too long, but I do appreciate your help.

Sincerest regards,

Huw.