Can I move the MDW file?

[Damien McBain]

I want to move the mdw file for my secured db to a new directory. Can I do
this then reassign it to the original db?

As far as I can tell from the kb this isn't possible?

Damien

 

['69 Camaro]

Hi, Damien.

I want to move the mdw file for my secured db to a new directory. Can I do
this then reassign it to the original db?

One doesn't need to "assign" the *.MDW file to a database. One joins the
workgroup (as indicated by the *.MDW, or workgroup information file) before
opening the database file or else one uses a command-line switch to indicate
which workgroup (the *.MDW file) to join before opening the database file.

When you move the *.MDW file to another directory, ensure that all users of
the database have "Full Control" Windows security permissions on that
directory. Also ensure that if the workgroup information file name is moved
to the same directory as the database file, the name of the workgroup
information file is not the same as the database file name. For example,
MyDB.MDB and MyDB.MDW should not be in the same directory, because both will
attempt to create or modify the same locking database file, MyDB.LDB.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Damien McBain]

Hi, Damien.


One doesn't need to "assign" the *.MDW file to a database. One joins
the workgroup (as indicated by the *.MDW, or workgroup information
file) before opening the database file or else one uses a
command-line switch to indicate which workgroup (the *.MDW file) to
join before opening the database file.

When you move the *.MDW file to another directory, ensure that all
users of the database have "Full Control" Windows security
permissions on that directory. Also ensure that if the workgroup
information file name is moved to the same directory as the database
file, the name of the workgroup information file is not the same as
the database file name. For example, MyDB.MDB and MyDB.MDW should
not be in the same directory, because both will attempt to create or
modify the same locking database file, MyDB.LDB.

HTH.

Gunny

Gotcha, I understand now.

Is there a better way to create / modify users and groups than using that
awful standard dialog? I can't even set a user's password in there, or force
them to create a password if I erase it.

It would be better if I could authenticate them on our domain and assign
permission via Windows rather than this mdw file thing, anyhow...

Thanks 4 the help Gunny

Damo

 

['69 Camaro]

Hi, Damien.

Is there a better way to create / modify users and groups than using that
awful standard dialog?

That "awful standard dialog" window is the _easy_ way. The hard way (at
least for non-programmers) is to use SQL or VBA code with the DAO library to
create/modify users and their permissions.

I can't even set a user's password in there

When you create a new user, close the database, then log in as the new user
and set a password. Create a password sufficiently difficult to remember,
such as hE4wbpQnLB8avP, and then close the database. Tell the users their
new User ID's and passwords, then give the users instructions on how to
change their passwords themselves. They'll usually make the effort to
change a password like this.

I can't even <SNIP> force
them to create a password if I erase it.

Whenever you reset a user's password, create a new one that is difficult to
remember and give the user the instructions on how to change it. If you
suspect that they've removed the password, then periodically try to open the
database using this user's UserID without a password. (You could write a
VBA routine to automate this.) If the database opens with that user's
UserID but without a password, then you set a new password for that UserID
and give it to the user. Explain that the new security features prevent
users from having a blank password after a certain period of time (24 hours?
72 hours? You decide what's best), and will create a random password for
that user and create a report for the DBA whenever a blank password is
found.

It would be better if I could authenticate them on our domain and assign
permission via Windows rather than this mdw file thing

You can. Have the Windows network administrator create a new Windows Group
and assign "Full Control" Windows security permissions on the directories
containing the database files and the workgroup information file to members
of that Group. Have the Windows network administrator remove all Windows
security permissions for all other Windows Groups and user accounts. Then,
have the Windows network administrator assign all users authorized to use
the database to this new Windows Group.

Any Windows user account that does not have authorization to use the
database has no Windows security permissions on these directories, not even
"List Contents," so unauthorized users will never even know the database is
there.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Damien McBain]

Hi, Damien.


That "awful standard dialog" window is the _easy_ way. The hard way
(at least for non-programmers) is to use SQL or VBA code with the DAO
library to create/modify users and their permissions.


When you create a new user, close the database, then log in as the
new user and set a password. Create a password sufficiently
difficult to remember, such as hE4wbpQnLB8avP, and then close the
database. Tell the users their new User ID's and passwords, then
give the users instructions on how to change their passwords
themselves. They'll usually make the effort to change a password
like this.

I was afraid you might say that. There are about 50 users to be created
<sigh>. Can I edit the mdw directly? There's a (hidden) table in there
called "MSysAccounts" which appears to be where the user and group main data
is stored. I'm reluctant to edit or add anything there is case I screw it up
(this db ap goes into prod on Friday!).

Whenever you reset a user's password, create a new one that is
difficult to remember and give the user the instructions on how to
change it. If you suspect that they've removed the password, then
periodically try to open the database using this user's UserID
without a password. (You could write a VBA routine to automate
this.) If the database opens with that user's UserID but without a
password, then you set a new password for that UserID and give it to
the user. Explain that the new security features prevent users from
having a blank password after a certain period of time (24 hours? 72
hours? You decide what's best), and will create a random password
for that user and create a report for the DBA whenever a blank
password is found.


You can. Have the Windows network administrator create a new Windows
Group and assign "Full Control" Windows security permissions on the
directories containing the database files and the workgroup
information file to members of that Group. Have the Windows network
administrator remove all Windows security permissions for all other
Windows Groups and user accounts. Then, have the Windows network
administrator assign all users authorized to use the database to this
new Windows Group.

Any Windows user account that does not have authorization to use the
database has no Windows security permissions on these directories,
not even "List Contents," so unauthorized users will never even know
the database is there.

I already do this. The admins made me the owner of this dir and assigned
permission to the relevant group of users. So I *can* control who can access
the db but I *can't* control which db objects the user can exec, mod etc
without using the workgroup info file.

One thing that scares me is that giving full control to the whole group
means that any of them could access the folder and delete everything in it.
The only saving grace here is that they access the db via Citrix nfuse as a
published ap, so no-one actually knows where the db is located (it wouldn't
be hard to find though).

Eventually I'm sure Access will support domain authentication with Windows
Server and remove the need for MDWs.

 

['69 Camaro]

Hi, Damien.

Can I edit the mdw directly?

I would not advise doing so. The passwords and SID's need to be added
correctly, and unless you have the encryption algorithm that Jet uses,
anything you type in manually will likely render your database unusable for
the UserID you are updating.

I *can't* control which db objects the user can exec, mod etc
without using the workgroup info file.

Actually, these permissions are stored in the database file itself, not the
workgroup information file. However, the workgroup information file is
necessary for authorized users to open the database, itself.

One thing that scares me is that giving full control to the whole group
means that any of them could access the folder and delete everything in

it.

This is one of the downsides of a file-based database. Make sure that
backups are made on a frequent basis in order to minimize disasters caused
by a mistaken deletion. Also, if you only give the users shortcuts to the
database file without mapping to the shared network directory, you'll
probably eliminate more than half of the users who will be able to find the
directory on their own by opening it in Windows Explorer.

Eventually I'm sure Access will support domain authentication with Windows
Server and remove the need for MDWs.

I wouldn't count on it!

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Damien McBain]

I wouldn't count on it!

DOH!

Thanks for your help m8, I've learnt a bit from your posts.

Damo

 

['69 Camaro]

You're welcome! Glad it helped.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)