If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Can I move the MDW file?
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 |
#2
|
|||
|
|||
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" wrote in message ... 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 |
#3
|
|||
|
|||
'69 Camaro wrote:
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 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 |
#4
|
|||
|
|||
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" wrote in message ... '69 Camaro wrote: 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 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 |
#5
|
|||
|
|||
'69 Camaro wrote:
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 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!). 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. 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. 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" wrote in message ... '69 Camaro wrote: 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 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 |
#6
|
|||
|
|||
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" wrote in message ... '69 Camaro wrote: 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 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!). 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. 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. 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" wrote in message ... '69 Camaro wrote: 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 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 |
#7
|
|||
|
|||
'69 Camaro wrote:
Eventually I'm sure Access will support domain authentication with Windows Server and remove the need for MDWs. I wouldn't count on it! DOH! Thanks for your help m8, I've learnt a bit from your posts. Damo |
#8
|
|||
|
|||
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.) "Damien McBain" wrote in message ... '69 Camaro wrote: Eventually I'm sure Access will support domain authentication with Windows Server and remove the need for MDWs. I wouldn't count on it! DOH! Thanks for your help m8, I've learnt a bit from your posts. Damo |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
URGENT: Mailing rule problems of filing in outlook express and hard copy file systems in real case | Teres | Outlook Express | 7 | August 14th, 2004 01:55 AM |
Application must be installed to run Error | Keith | Setup, Installing & Configuration | 1 | June 29th, 2004 03:02 AM |
Unsafe Attachments | Ron | Installation & Setup | 2 | June 9th, 2004 01:55 AM |
Product Key for Office XP | P.G.Indiana | Setup, Installing & Configuration | 1 | June 7th, 2004 03:22 AM |