|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
Sorry for the long post, but I'm hoping to give enough info to get a quick
resolution. Thanks in advance.
In testing stages of a security on database... I had security set and was
testing it with another user and myself. The db was on a network server, and
only one of us could get in at a time. (Hadn't yet taken steps to split db
into front/back ends.) Her login was working, and I could access through my
login or through Admin... Not sure what one thing triggered the malfunction
today.
Someone else, who was trying to help her in my absence, had deleted the db
shortcut and created a new one. I didn't pay attention to the logon that
popped up and went through Tools/Security to make sure she was added to the
database. Turns out it was her server login (used at Start Up) that I added.
Now it appears the security applied to our main system of record (DB#1),
which is Access based is linked the .mdw of the test database (DB#2).
When she tried logging into DB#1 she was getting a logon prompt, which is
not required as it is initiated during server login. If I was in either db,
she couldn't get in either.
I've deleted the .mdw file for the test db, and now we can get in DB#1
(separate, or at the same time), but neither of us can get in DB#2. I was
smart enough to save the .mdw file, so it's lost.
How can I fix this mess and salvage the test databse, which now has a lot of
data in it. The last backup was Many data entry hours ago.
Thank you,
Janice
|
|
Hi Janice.
"jct" <jct[ at ]discussions.microsoft.com> wrote in message
news:66E6F4C1-CE2A-4055-A0F8-44EDD3A3408F[ at ]microsoft.com...
[Quoted Text] >
> I've deleted the .mdw file for the test db, and now we can get in DB#1
> (separate, or at the same time), but neither of us can get in DB#2. I was
> smart enough to save the .mdw file, so it's lost.
Oh dear, you've just learned the hard way that you should only work on
backups when you're learning security.
>
> How can I fix this mess and salvage the test databse, which now has a lot
> of
> data in it. The last backup was Many data entry hours ago.
>
There is no legitimate way to get into a secured file without it's workgroup
file (mdw) so you're now on the path of paying for a utility (of which there
are may if you care to Google) to break into it. Is your server not backed
up periodically?
Keith.
www.keithwilby.com
|
|
how long it took to become and security specialist and MSCDA
Cameron
"jct" wrote:
[Quoted Text] > Sorry for the long post, but I'm hoping to give enough info to get a quick
> resolution. Thanks in advance.
>
> In testing stages of a security on database... I had security set and was
> testing it with another user and myself. The db was on a network server, and
> only one of us could get in at a time. (Hadn't yet taken steps to split db
> into front/back ends.) Her login was working, and I could access through my
> login or through Admin... Not sure what one thing triggered the malfunction
> today.
>
> Someone else, who was trying to help her in my absence, had deleted the db
> shortcut and created a new one. I didn't pay attention to the logon that
> popped up and went through Tools/Security to make sure she was added to the
> database. Turns out it was her server login (used at Start Up) that I added.
>
> Now it appears the security applied to our main system of record (DB#1),
> which is Access based is linked the .mdw of the test database (DB#2).
>
> When she tried logging into DB#1 she was getting a logon prompt, which is
> not required as it is initiated during server login. If I was in either db,
> she couldn't get in either.
>
> I've deleted the .mdw file for the test db, and now we can get in DB#1
> (separate, or at the same time), but neither of us can get in DB#2. I was
> smart enough to save the .mdw file, so it's lost.
>
> How can I fix this mess and salvage the test databse, which now has a lot of
> data in it. The last backup was Many data entry hours ago.
>
> Thank you,
> Janice
|
|
I mistyped. I did save the MDW can restore it, however I still have the
problem of the two unrelated databases being linked through security.
DB#1, the company's main system, should not ask for a login but now it does
(as if it were DB#2). How do I delete the security I set on DB#1, which was
intended for DB#2? Is this in the System MDW, or...??
Janice
"Cameron" wrote:
[Quoted Text] > how long it took to become and security specialist and MSCDA
>
> Cameron
>
> "jct" wrote:
>
> > Sorry for the long post, but I'm hoping to give enough info to get a quick
> > resolution. Thanks in advance.
> >
> > In testing stages of a security on database... I had security set and was
> > testing it with another user and myself. The db was on a network server, and
> > only one of us could get in at a time. (Hadn't yet taken steps to split db
> > into front/back ends.) Her login was working, and I could access through my
> > login or through Admin... Not sure what one thing triggered the malfunction
> > today.
> >
> > Someone else, who was trying to help her in my absence, had deleted the db
> > shortcut and created a new one. I didn't pay attention to the logon that
> > popped up and went through Tools/Security to make sure she was added to the
> > database. Turns out it was her server login (used at Start Up) that I added.
> >
> > Now it appears the security applied to our main system of record (DB#1),
> > which is Access based is linked the .mdw of the test database (DB#2).
> >
> > When she tried logging into DB#1 she was getting a logon prompt, which is
> > not required as it is initiated during server login. If I was in either db,
> > she couldn't get in either.
> >
> > I've deleted the .mdw file for the test db, and now we can get in DB#1
> > (separate, or at the same time), but neither of us can get in DB#2. I was
> > smart enough to save the .mdw file, so it's lost.
> >
> > How can I fix this mess and salvage the test databse, which now has a lot of
> > data in it. The last backup was Many data entry hours ago.
> >
> > Thank you,
> > Janice
|
|
jct wrote:
[Quoted Text] > I mistyped. I did save the MDW can restore it, however I still have the
> problem of the two unrelated databases being linked through security.
>
> DB#1, the company's main system, should not ask for a login but now it does
> (as if it were DB#2). How do I delete the security I set on DB#1, which was
> intended for DB#2? Is this in the System MDW, or...??
>
> Janice
You're confused ;-)
If your PC asks for logon credentials then you are joined to a modified
WIF (mdw) and you need to re-join the default "system.mdw". If you've
modified the default WIF then delete or move it and Access (2k and
above) will re-generate a new, clean "system.mdw" on startup.
HTH - Keith.
www.keithwilby.com
|
|
I'm still confused. Still learning some of this... Not sure what this means:
>you are joined to a modified
> WIF (mdw) and you need to re-join the default "system.mdw".
If I open up DB#2 (the one I developed and was testing) and try to open up
DB#1 (the main system db which has an Access interface), a login prompt
appears for DB#1 (which was never there before). Prior to this nightmare,
once I logged into my machine (thus accessing the network) I did not need a
login to open DB#1.
I removed DB#2 from the server, and am accessing direct from my machine
while I clean this mess up. Are you saying that by deleting system.mdw from
my machine it will clear the login prompt from DB#1?
Sorry, I need a little remedial (and possibly step-by-step) help here...
Thank you,
Janice
"Keith" wrote:
[Quoted Text] > jct wrote:
> > I mistyped. I did save the MDW can restore it, however I still have the
> > problem of the two unrelated databases being linked through security.
> >
> > DB#1, the company's main system, should not ask for a login but now it does
> > (as if it were DB#2). How do I delete the security I set on DB#1, which was
> > intended for DB#2? Is this in the System MDW, or...??
> >
> > Janice
>
> You're confused ;-)
>
> If your PC asks for logon credentials then you are joined to a modified
> WIF (mdw) and you need to re-join the default "system.mdw". If you've
> modified the default WIF then delete or move it and Access (2k and
> above) will re-generate a new, clean "system.mdw" on startup.
>
> HTH - Keith.
> www.keithwilby.com
>
|
|
This is how Access security works. If you create security on any database in
Access, all Access databases will prompt you to login regardless. This is
the default by design. What you need to do is create a shortcut on your
desktop to the database with security and set the shortcut to open the
database, open the correct mdw file. For the other databases to work without
a login, you need to go back to the Workgroup program and join to the
System.mdw file. If joining this does not allow your other databases to
work, then see next paragraph. The Workgroup is set within Access 2003 and
has a separate file for all other versions. You should be able to get to
this just by opening Access without opening any databases.
If you used the System.mdw file to create the security and did not give it a
new name, then you need to establish the generic System.mdw file that gets
installed when you install Access. This can be as simple as copying the
System.mdw file from someone else's machine. However before you do this,
keep a copy the current System.mdw file in case it does contain you current
security info and you use it for your shortcut mentioned in the first
paragraph.
Another thing to remember is passwords are not implemented when you first
set up security. All you are doing is setting PIDs. Therefore when first
opening the database you do not need to enter a password, you just need to
enter the username. Hopefully, somewhere you gave yourself Admin privileges
when you setup the PIDs.
Microsoft's Knowledge base has an excellent whitepaper on setting up
security for Access. I would suggest you search for this whitepaper on the
website before you go any further in this matter. The reason for this is
once you mess up security on the database, there is no way to recover the
database data.
"jct" <jct[ at ]discussions.microsoft.com> wrote in message
news:CA0AF930-4FD9-4F91-BE82-7A11D8E9EB93[ at ]microsoft.com...
[Quoted Text] > I'm still confused. Still learning some of this... Not sure what this
> means:
> >you are joined to a modified
> > WIF (mdw) and you need to re-join the default "system.mdw".
>
> If I open up DB#2 (the one I developed and was testing) and try to open up
> DB#1 (the main system db which has an Access interface), a login prompt
> appears for DB#1 (which was never there before). Prior to this nightmare,
> once I logged into my machine (thus accessing the network) I did not need
> a
> login to open DB#1.
>
> I removed DB#2 from the server, and am accessing direct from my machine
> while I clean this mess up. Are you saying that by deleting system.mdw
> from
> my machine it will clear the login prompt from DB#1?
>
> Sorry, I need a little remedial (and possibly step-by-step) help here...
> Thank you,
>
> Janice
>
>
> "Keith" wrote:
>
>> jct wrote:
>> > I mistyped. I did save the MDW can restore it, however I still have the
>> > problem of the two unrelated databases being linked through security.
>> >
>> > DB#1, the company's main system, should not ask for a login but now it
>> > does
>> > (as if it were DB#2). How do I delete the security I set on DB#1, which
>> > was
>> > intended for DB#2? Is this in the System MDW, or...??
>> >
>> > Janice
>>
>> You're confused ;-)
>>
>> If your PC asks for logon credentials then you are joined to a modified
>> WIF (mdw) and you need to re-join the default "system.mdw". If you've
>> modified the default WIF then delete or move it and Access (2k and
>> above) will re-generate a new, clean "system.mdw" on startup.
>>
>> HTH - Keith.
>> www.keithwilby.com
>>
|
|
"G. Vaught" <glvaught[ at ]hotmail.com> wrote in message
news:uXZqHESqGHA.3564[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > If you create security on any database in Access, all Access databases
> will prompt you to login regardless. This is the default by design.
Well not quite, just to clarify, this is the behaviour you'll get if you
either modify the default WIF or join your custom WIF by default. You
should NEVER IMO modify the default system.mdw but create your custom WIF
and use a desktop shortcut to join it on a session-by-session basis (which
is what you go on to state).
Keith.
|
|
"jct" <jct[ at ]discussions.microsoft.com> wrote in message
news:CA0AF930-4FD9-4F91-BE82-7A11D8E9EB93[ at ]microsoft.com...
[Quoted Text] > I'm still confused. Still learning some of this... Not sure what this
> means:
> >you are joined to a modified
> > WIF (mdw) and you need to re-join the default "system.mdw".
>
I think you need to start with a clean sheet and read the MS FAQ. There's a
link to it on my web site and it's essential reading if you want to
understand how security works in order to set it up correctly. Be aware
that there's no filler in the FAQ, all of it is pertinent.
Keith.
www.keithwilby.com
|
|
G. Vaught wrote:
[Quoted Text] > The Workgroup is set within Access 2003 and has a separate
> file for all other versions.
The workgroup administrator is also built in to 2002.
> If you used the System.mdw file to create the security and did not
> give it a new name
Are you suggesting that using system.mdw and giving it a new name is OK?
(it's not)
>, then you need to establish the generic System.mdw
> file that gets installed when you install Access.
>
> Another thing to remember is passwords are not implemented when you
> first set up security. All you are doing is setting PIDs.
Not necessarily true. You can set passwords if you use the security wizard
in 2002 or 2003.
> The reason
> for this is once you mess up security on the database, there is no
> way to recover the database data.
Again not true. If you mess things up, it's quite likely you'll be able to
undo or get around whatever you've done, especially if you've messed it up.
|
|
jct wrote:
[Quoted Text] > Sorry for the long post, but I'm hoping to give enough info to get a
> quick resolution. Thanks in advance.
>
> In testing stages of a security on database... I had security set and
> was testing it with another user and myself. The db was on a network
> server, and only one of us could get in at a time. (Hadn't yet taken
> steps to split db into front/back ends.) Her login was working, and I
> could access through my login or through Admin... Not sure what one
> thing triggered the malfunction today.
Is this DB#1 or DB#2?
Only one getting in at a time suggests that the windows user does not have
enough permissions on the folder where the mdb is. All users need
read/write/create/delete permissions on the folder.
> Someone else, who was trying to help her in my absence, had deleted
> the db shortcut and created a new one. I didn't pay attention to the
> logon that popped up and went through Tools/Security to make sure she
> was added to the database. Turns out it was her server login (used at
> Start Up) that I added.
It's possible that this 'someone else' created a shortcut using the wrong
mdw file, or none at all meaning that it now was using system.mdw. However
since you got a login prompt, I doubt it. If you didn't pay attention to
the login, then how do you know what username you logged in with; what
password did you use. From the password you used, you should know what the
username must have been. "Turns out it was her server login" - how do you
know?
>
> Now it appears the security applied to our main system of record
> (DB#1), which is Access based is linked the .mdw of the test database
> (DB#2).
How did you come to this conclusion?
> When she tried logging into DB#1 she was getting a logon prompt,
> which is not required as it is initiated during server login. If I
> was in either db, she couldn't get in either.
How did she log into DB#1 - via a shortcut or double-clicking in Windows
Explorer? What steps?
> I've deleted the .mdw file for the test db, and now we can get in DB#1
> (separate, or at the same time), but neither of us can get in DB#2. I
> was smart enough to save the .mdw file, so it's lost.
Which is the one that you secured? DB1 or 2? What version of Access?
--
Joan Wild
Microsoft Access MVP
|
|
I am working on different Access databases for my company. I am
expected to provide security features and make sure that the databases
are running well. There are about 8 databases being used so far, each
with multiple users.
I have tried setting up security features on the first database. After
following the right procedure in User-Security and giving permission to
users, I went to a collegue's computer to test. She had full access
and admin privileges. There was no logon prompt.
This was very disappointing because I thought I followed the procedure
very carefully.
We are using a common drive on the network.
Please help me get this thing done!
Billy
|
|
Billy wrote:
[Quoted Text] > I am working on different Access databases for my company. I am
> expected to provide security features and make sure that the databases
> are running well. There are about 8 databases being used so far, each
> with multiple users.
> I have tried setting up security features on the first database.
> After following the right procedure in User-Security and giving
> permission to users, I went to a collegue's computer to test. She
> had full access and admin privileges. There was no logon prompt.
> This was very disappointing because I thought I followed the procedure
> very carefully.
> We are using a common drive on the network.
> Please help me get this thing done!
> Billy
Get a different procedure to follow and try again because that definitely
means you missed one or more steps. I suggest you try the procedure as
outlined at the link below...
http://www.jmwild.com/security02.htm
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
|
|
Do I need to delete the rest of the files that have been created for
this to be successful?
Rick Brandt wrote:
[Quoted Text] > Billy wrote: > > I am working on different Access databases for my company. I am > > expected to provide security features and make sure that the databases > > are running well. There are about 8 databases being used so far, each > > with multiple users. > > I have tried setting up security features on the first database. > > After following the right procedure in User-Security and giving > > permission to users, I went to a collegue's computer to test. She > > had full access and admin privileges. There was no logon prompt. > > This was very disappointing because I thought I followed the procedure > > very carefully. > > We are using a common drive on the network. > > Please help me get this thing done! > > Billy > > Get a different procedure to follow and try again because that definitely > means you missed one or more steps. I suggest you try the procedure as > outlined at the link below... > > http://www.jmwild.com/security02.htm> > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com
|
|
Billy wrote:
[Quoted Text] > Do I need to delete the rest of the files that have been created for
> this to be successful?
Most likely. Security learning is best done on junk files until you are
comfortable with it.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
|
|
I followed the procedure, I am showing it is running "Enhancing
Security" but kind of stuck. Do I need to close the database or just
wait until it stops running and the green light is gone?
Thanks a lot for your help.
Rick Brandt wrote:
[Quoted Text] > Billy wrote:
> > Do I need to delete the rest of the files that have been created for
> > this to be successful?
>
> Most likely. Security learning is best done on junk files until you are
> comfortable with it.
>
> --
> Rick Brandt, Microsoft Access MVP
> Email (as appropriate) to...
> RBrandt at Hunter dot com
|
|
I am really in some big problem here guys. Add or Remove buttons are
greyed out in the User/Accounts. What do I need to do? Got some
pressure on me here.
Billy
Billy wrote:
[Quoted Text] > I followed the procedure, I am showing it is running "Enhancing
> Security" but kind of stuck. Do I need to close the database or just
> wait until it stops running and the green light is gone?
> Thanks a lot for your help.
>
> Rick Brandt wrote:
> > Billy wrote:
> > > Do I need to delete the rest of the files that have been created for
> > > this to be successful?
> >
> > Most likely. Security learning is best done on junk files until you are
> > comfortable with it.
> >
> > --
> > Rick Brandt, Microsoft Access MVP
> > Email (as appropriate) to...
> > RBrandt at Hunter dot com
|
|
You need to log in as a member of the Admins Group - log in with that
username and you can delete/add users/groups.
--
Joan Wild
Microsoft Access MVP
Billy wrote:
[Quoted Text] > I am really in some big problem here guys. Add or Remove buttons are
> greyed out in the User/Accounts. What do I need to do? Got some
> pressure on me here.
> Billy
> Billy wrote:
>> I followed the procedure, I am showing it is running "Enhancing
>> Security" but kind of stuck. Do I need to close the database or just
>> wait until it stops running and the green light is gone?
>> Thanks a lot for your help.
>>
>> Rick Brandt wrote:
>>> Billy wrote:
>>>> Do I need to delete the rest of the files that have been created
>>>> for this to be successful?
>>>
>>> Most likely. Security learning is best done on junk files until
>>> you are comfortable with it.
>>>
>>> --
>>> Rick Brandt, Microsoft Access MVP
>>> Email (as appropriate) to...
>>> RBrandt at Hunter dot com
|
|
I have tried this, not working. I have been trying to set up security
features. I set up about 3 mdw files that I have been using. Could
this be the cause of the problem?
Billy
Joan Wild wrote:
[Quoted Text] > You need to log in as a member of the Admins Group - log in with that
> username and you can delete/add users/groups.
>
> --
> Joan Wild
> Microsoft Access MVP
>
> Billy wrote:
> > I am really in some big problem here guys. Add or Remove buttons are
> > greyed out in the User/Accounts. What do I need to do? Got some
> > pressure on me here.
> > Billy
> > Billy wrote:
> >> I followed the procedure, I am showing it is running "Enhancing
> >> Security" but kind of stuck. Do I need to close the database or just
> >> wait until it stops running and the green light is gone?
> >> Thanks a lot for your help.
> >>
> >> Rick Brandt wrote:
> >>> Billy wrote:
> >>>> Do I need to delete the rest of the files that have been created
> >>>> for this to be successful?
> >>>
> >>> Most likely. Security learning is best done on junk files until
> >>> you are comfortable with it.
> >>>
> >>> --
> >>> Rick Brandt, Microsoft Access MVP
> >>> Email (as appropriate) to...
> >>> RBrandt at Hunter dot com
|
|
Probably in your multiple attempts to set up security, you created the three
mdw files.
Access ships with a workgroup file called system.mdw that's used in every
session (even unsecured databases). It uses this one and silently logs you
in as a user called 'Admin'.
When you secure a database, you create a new workgroup file. You only need
one.
I gather from this thread that you are practising on a copy of your
database.
I suggest at this point, that you go to your backup of the unsecured mdb,
delete all the mdw files you created, and start over.
Also ensure that you don't modify the default system.mdw workgroup.
You need to follow every step outlined in securing your database or it won't
work properly.
Some resources:
Security FAQ
http://support.microsoft.com/?id=207793
Security Whitepaper
http://support.microsoft.com/?id=148555
Although the whitepaper is old, it contains information to help you
understand security.
I've also outlined the detailed steps at
www.jmwild.com/AccessSecurity.htm
--
Joan Wild
Microsoft Access MVP
Billy wrote:
[Quoted Text] > I have tried this, not working. I have been trying to set up security
> features. I set up about 3 mdw files that I have been using. Could
> this be the cause of the problem?
> Billy
> Joan Wild wrote:
>> You need to log in as a member of the Admins Group - log in with that
>> username and you can delete/add users/groups.
>>
>> --
>> Joan Wild
>> Microsoft Access MVP
>>
>> Billy wrote:
>>> I am really in some big problem here guys. Add or Remove buttons
>>> are greyed out in the User/Accounts. What do I need to do? Got some
>>> pressure on me here.
>>> Billy
>>> Billy wrote:
>>>> I followed the procedure, I am showing it is running "Enhancing
>>>> Security" but kind of stuck. Do I need to close the database or
>>>> just wait until it stops running and the green light is gone?
>>>> Thanks a lot for your help.
>>>>
>>>> Rick Brandt wrote:
>>>>> Billy wrote:
>>>>>> Do I need to delete the rest of the files that have been created
>>>>>> for this to be successful?
>>>>>
>>>>> Most likely. Security learning is best done on junk files until
>>>>> you are comfortable with it.
>>>>>
>>>>> --
>>>>> Rick Brandt, Microsoft Access MVP
>>>>> Email (as appropriate) to...
>>>>> RBrandt at Hunter dot com
|
|
Joan,
Thanks for your advise but when I join my functioning mdw file to the
system, Add/Remove is greyed out. I get an account that I created at
the beginning and it would not let me change anything. I hope I have
not done any damage to the system mdw.
Help please
Billy
Joan Wild wrote:
[Quoted Text] > Probably in your multiple attempts to set up security, you created the three > mdw files. > > Access ships with a workgroup file called system.mdw that's used in every > session (even unsecured databases). It uses this one and silently logs you > in as a user called 'Admin'. > > When you secure a database, you create a new workgroup file. You only need > one. > > I gather from this thread that you are practising on a copy of your > database. > > I suggest at this point, that you go to your backup of the unsecured mdb, > delete all the mdw files you created, and start over. > > Also ensure that you don't modify the default system.mdw workgroup. > > You need to follow every step outlined in securing your database or it won't > work properly. > > Some resources: > > Security FAQ > http://support.microsoft.com/?id=207793> > Security Whitepaper > http://support.microsoft.com/?id=148555> > Although the whitepaper is old, it contains information to help you > understand security. > > I've also outlined the detailed steps at > www.jmwild.com/AccessSecurity.htm > > > -- > Joan Wild > Microsoft Access MVP > > Billy wrote: > > I have tried this, not working. I have been trying to set up security > > features. I set up about 3 mdw files that I have been using. Could > > this be the cause of the problem? > > Billy > > Joan Wild wrote: > >> You need to log in as a member of the Admins Group - log in with that > >> username and you can delete/add users/groups. > >> > >> -- > >> Joan Wild > >> Microsoft Access MVP > >> > >> Billy wrote: > >>> I am really in some big problem here guys. Add or Remove buttons > >>> are greyed out in the User/Accounts. What do I need to do? Got some > >>> pressure on me here. > >>> Billy > >>> Billy wrote: > >>>> I followed the procedure, I am showing it is running "Enhancing > >>>> Security" but kind of stuck. Do I need to close the database or > >>>> just wait until it stops running and the green light is gone? > >>>> Thanks a lot for your help. > >>>> > >>>> Rick Brandt wrote: > >>>>> Billy wrote: > >>>>>> Do I need to delete the rest of the files that have been created > >>>>>> for this to be successful? > >>>>> > >>>>> Most likely. Security learning is best done on junk files until > >>>>> you are comfortable with it. > >>>>> > >>>>> -- > >>>>> Rick Brandt, Microsoft Access MVP > >>>>> Email (as appropriate) to... > >>>>> RBrandt at Hunter dot com
|
|
Billy wrote:
[Quoted Text] > Joan,
> Thanks for your advise but when I join my functioning mdw file to the
> system, Add/Remove is greyed out.
I'm not sure what you mean by 'functioning'. Any mdw will function.
> I get an account that I created at
> the beginning and it would not let me change anything.
You 'get' an account? I don't understand this. When you see the login
dialog, the username will be filled in with the last username that used
Access. You can change that username to another one. You need to log in
using a username that is a member of the Admins Group.
Or it's possible that you aren't using the correct mdw file - try one of the
others.
--
Joan Wild
Microsoft Access MVP
|
|
Everything seems to be going well at this point! Now how do I
distribute the database to the network or rather how do I create a
shortcut that can be accessed by everybody on the common drive?
Billy
Joan Wild wrote:
[Quoted Text] > Billy wrote:
> > Joan,
> > Thanks for your advise but when I join my functioning mdw file to the
> > system, Add/Remove is greyed out.
>
> I'm not sure what you mean by 'functioning'. Any mdw will function.
>
> > I get an account that I created at
> > the beginning and it would not let me change anything.
>
> You 'get' an account? I don't understand this. When you see the login
> dialog, the username will be filled in with the last username that used
> Access. You can change that username to another one. You need to log in
> using a username that is a member of the Admins Group.
>
> Or it's possible that you aren't using the correct mdw file - try one of the
> others.
>
>
> --
> Joan Wild
> Microsoft Access MVP
|
|
You need to copy the secure mdw and the mdb to a folder on the server that
everyone has access to. All users will need read/write/create/delete
windows permissions on that folder.
You can give each user a desktop shortcut the uses the secure mdw and opens
the secure mdb. The target would look like:
"path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure mdw"
It is highly recommended that you split the database. Put the backend
(tables/relationships only) mdb on the server. A copy of the frontend (all
other objects, and table links to the backend) mdb would go on each user's
computer. You'd modify the shortcut above so that the path to secure mdb
would be the path to the frontend.
If everyone has Access installed in the same folder, and the frontend is
installed in the same location on each PC, you can copy the shortcut to each
person.
Since you've secured it, you shouldn't use the database splitter wizard, as
that will result in an unsecure backend mdb. Instead split it manually.
See www.jmwild.com/SplitSecure.htm
--
Joan Wild
Microsoft Access MVP
Billy wrote:
[Quoted Text] > Everything seems to be going well at this point! Now how do I
> distribute the database to the network or rather how do I create a
> shortcut that can be accessed by everybody on the common drive?
> Billy
|
|
Joan,
Your help is great, but would you please provide step by step process
of creating a shortcut on the network as well as securing the backend
and/or frontend.
The secured database is seated on my desktop. I copied it to a folder
in the network..successful, I also copied the mdw file to the same
folder....successful, however, I realised that the mdw file needed me
to import data..(is this normal?). At the same time, the mdw did not
show everybody shown on the one-step security wizard report...(is this
also normal?). If you have some links like the one you sent yesterday,
I would appreciate. I have to admit that it is the first time I am
securing a database on my own.
Thanks for your help so far.
Billy
Joan Wild wrote:
[Quoted Text] > You need to copy the secure mdw and the mdb to a folder on the server that
> everyone has access to. All users will need read/write/create/delete
> windows permissions on that folder.
>
> You can give each user a desktop shortcut the uses the secure mdw and opens
> the secure mdb. The target would look like:
> "path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure mdw"
>
> It is highly recommended that you split the database. Put the backend
> (tables/relationships only) mdb on the server. A copy of the frontend (all
> other objects, and table links to the backend) mdb would go on each user's
> computer. You'd modify the shortcut above so that the path to secure mdb
> would be the path to the frontend.
>
> If everyone has Access installed in the same folder, and the frontend is
> installed in the same location on each PC, you can copy the shortcut to each
> person.
>
> Since you've secured it, you shouldn't use the database splitter wizard, as
> that will result in an unsecure backend mdb. Instead split it manually.
>
> See www.jmwild.com/SplitSecure.htm
>
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
> Billy wrote:
> > Everything seems to be going well at this point! Now how do I
> > distribute the database to the network or rather how do I create a
> > shortcut that can be accessed by everybody on the common drive?
> > Billy
|
|
You do not create a shortcut on the network.
1. Copy the backend to the server (you've done this).
2. Copy the secure mdw to the server(you've done this).
However you said the mdw needed you to import data. Can you describe
exactly the messages you received. There is no need to import or do
anything to the mdw.
Mdw did not show all users as per one-step security wizard report. I
believe you said you had multiple mdw files and so likely there is a mix of
which one should be used. I suggest you revert to your unsecured database
and start over. You need only one secure mdw. Once you have it done, it's
that mdw that goes on the server. And it *will* contain all the users you
need.
Is your database split right now?
Yes - Good put the backend on the server. Open the frontend on your PC, and
use Tools, Linked Table Manager, and refresh the links; be sure to put a
check at the bottom to prompt for location and choose the location of the
backend on the server.
No - Split the database. See www.jmwild.com/SplitSecure.htm for steps. Put
the backend on the server and refresh the links as per the above.
If the wizard created a desktop shortcut for you on your PC, right-click it
and choose properties. It'll open to the Shortcut tab and the Target line
will be selected. The target will take the form similar to:
"path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure mdw"
secure mdb will be the original database on your PC - modify it (if
necessary) to reflect the path to the frontend on your c: drive.
path to secure mdw will be the secure mdw you used to secure your mdb
(somewhere on your C: drive) - change the path to reflect the location of
the secure mdw on the server.
Now, you'll have the backend and secure mdw on the server, a copy of the
frontend on your PC, and a shortcut on your desktop.
To set up other users you can just copy the frontend from your PC to them.
In addition you can copy the shortcut from your desktop to them (a shortcut
is just a file with a lnk extension). Ensure that you put the frontend in
the same location on their PC as it is in your's OR if you put it in a
different location, then modify the shortcut on *their* PC to reflect the
location of the frontend i.e. the target would look like:
"path to msaccess.exe" "path to frontend" /wrkgrp "path to secure mdw on
server"
and example:
"C:\Program Files\Microsoft Office\Office11\msaccess.exe"
"c:\MyApp\frontend.mdb" /wrkgrp "F:\databasefiles\secure.mdw"
Just another little wrinkle, but you can use the UNC pathname for the mdw;
i.e. \\servername\path\secure.mdw rather than 'F:' drive; this way you don't
have to worry about someone having a different drive mapping than you.
--
Joan Wild
Microsoft Access MVP
Billy wrote:
[Quoted Text] > Joan,
> Your help is great, but would you please provide step by step process
> of creating a shortcut on the network as well as securing the backend
> and/or frontend.
> The secured database is seated on my desktop. I copied it to a folder
> in the network..successful, I also copied the mdw file to the same
> folder....successful, however, I realised that the mdw file needed me
> to import data..(is this normal?). At the same time, the mdw did not
> show everybody shown on the one-step security wizard report...(is this
> also normal?). If you have some links like the one you sent
> yesterday, I would appreciate. I have to admit that it is the first
> time I am securing a database on my own.
> Thanks for your help so far.
> Billy
> Joan Wild wrote:
>> You need to copy the secure mdw and the mdb to a folder on the
>> server that everyone has access to. All users will need
>> read/write/create/delete windows permissions on that folder.
>>
>> You can give each user a desktop shortcut the uses the secure mdw
>> and opens the secure mdb. The target would look like:
>> "path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure
>> mdw"
>>
>> It is highly recommended that you split the database. Put the
>> backend (tables/relationships only) mdb on the server. A copy of
>> the frontend (all other objects, and table links to the backend) mdb
>> would go on each user's computer. You'd modify the shortcut above
>> so that the path to secure mdb would be the path to the frontend.
>>
>> If everyone has Access installed in the same folder, and the
>> frontend is installed in the same location on each PC, you can copy
>> the shortcut to each person.
>>
>> Since you've secured it, you shouldn't use the database splitter
>> wizard, as that will result in an unsecure backend mdb. Instead
>> split it manually.
>>
>> See www.jmwild.com/SplitSecure.htm
>>
>>
>>
>> --
>> Joan Wild
>> Microsoft Access MVP
>>
>> Billy wrote:
>>> Everything seems to be going well at this point! Now how do I
>>> distribute the database to the network or rather how do I create a
>>> shortcut that can be accessed by everybody on the common drive?
>>> Billy
|
|
Thanks alot Joan for this info.
I have followed the right procedure but now it is taking time before
the report prints.
I have been waiting for almost 1 hour for it to complete enhancing
security..(is this normal?). I restarted the whole process and deleted
the other .mdw files I had created earlier.
I hope I can finish it soon.
Billy
Joan Wild wrote:
[Quoted Text] > You do not create a shortcut on the network.
>
> 1. Copy the backend to the server (you've done this).
> 2. Copy the secure mdw to the server(you've done this).
> However you said the mdw needed you to import data. Can you describe
> exactly the messages you received. There is no need to import or do
> anything to the mdw.
> Mdw did not show all users as per one-step security wizard report. I
> believe you said you had multiple mdw files and so likely there is a mix of
> which one should be used. I suggest you revert to your unsecured database
> and start over. You need only one secure mdw. Once you have it done, it's
> that mdw that goes on the server. And it *will* contain all the users you
> need.
>
> Is your database split right now?
> Yes - Good put the backend on the server. Open the frontend on your PC, and
> use Tools, Linked Table Manager, and refresh the links; be sure to put a
> check at the bottom to prompt for location and choose the location of the
> backend on the server.
> No - Split the database. See www.jmwild.com/SplitSecure.htm for steps. Put
> the backend on the server and refresh the links as per the above.
>
> If the wizard created a desktop shortcut for you on your PC, right-click it
> and choose properties. It'll open to the Shortcut tab and the Target line
> will be selected. The target will take the form similar to:
> "path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure mdw"
> secure mdb will be the original database on your PC - modify it (if
> necessary) to reflect the path to the frontend on your c: drive.
> path to secure mdw will be the secure mdw you used to secure your mdb
> (somewhere on your C: drive) - change the path to reflect the location of
> the secure mdw on the server.
>
> Now, you'll have the backend and secure mdw on the server, a copy of the
> frontend on your PC, and a shortcut on your desktop.
>
> To set up other users you can just copy the frontend from your PC to them.
> In addition you can copy the shortcut from your desktop to them (a shortcut
> is just a file with a lnk extension). Ensure that you put the frontend in
> the same location on their PC as it is in your's OR if you put it in a
> different location, then modify the shortcut on *their* PC to reflect the
> location of the frontend i.e. the target would look like:
> "path to msaccess.exe" "path to frontend" /wrkgrp "path to secure mdw on
> server"
> and example:
> "C:\Program Files\Microsoft Office\Office11\msaccess.exe"
> "c:\MyApp\frontend.mdb" /wrkgrp "F:\databasefiles\secure.mdw"
>
> Just another little wrinkle, but you can use the UNC pathname for the mdw;
> i.e. \\servername\path\secure.mdw rather than 'F:' drive; this way you don't
> have to worry about someone having a different drive mapping than you.
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
> Billy wrote:
> > Joan,
> > Your help is great, but would you please provide step by step process
> > of creating a shortcut on the network as well as securing the backend
> > and/or frontend.
> > The secured database is seated on my desktop. I copied it to a folder
> > in the network..successful, I also copied the mdw file to the same
> > folder....successful, however, I realised that the mdw file needed me
> > to import data..(is this normal?). At the same time, the mdw did not
> > show everybody shown on the one-step security wizard report...(is this
> > also normal?). If you have some links like the one you sent
> > yesterday, I would appreciate. I have to admit that it is the first
> > time I am securing a database on my own.
> > Thanks for your help so far.
> > Billy
> > Joan Wild wrote:
> >> You need to copy the secure mdw and the mdb to a folder on the
> >> server that everyone has access to. All users will need
> >> read/write/create/delete windows permissions on that folder.
> >>
> >> You can give each user a desktop shortcut the uses the secure mdw
> >> and opens the secure mdb. The target would look like:
> >> "path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure
> >> mdw"
> >>
> >> It is highly recommended that you split the database. Put the
> >> backend (tables/relationships only) mdb on the server. A copy of
> >> the frontend (all other objects, and table links to the backend) mdb
> >> would go on each user's computer. You'd modify the shortcut above
> >> so that the path to secure mdb would be the path to the frontend.
> >>
> >> If everyone has Access installed in the same folder, and the
> >> frontend is installed in the same location on each PC, you can copy
> >> the shortcut to each person.
> >>
> >> Since you've secured it, you shouldn't use the database splitter
> >> wizard, as that will result in an unsecure backend mdb. Instead
> >> split it manually.
> >>
> >> See www.jmwild.com/SplitSecure.htm
> >>
> >>
> >>
> >> --
> >> Joan Wild
> >> Microsoft Access MVP
> >>
> >> Billy wrote:
> >>> Everything seems to be going well at this point! Now how do I
> >>> distribute the database to the network or rather how do I create a
> >>> shortcut that can be accessed by everybody on the common drive?
> >>> Billy
|
|
It is unusual for it to take that long.
Did you start with the original unsecured copy of your database?
Did you compile and compact the mdb before running the wizard?
--
Joan Wild
Microsoft Access MVP
Billy wrote:
[Quoted Text] > Thanks alot Joan for this info.
> I have followed the right procedure but now it is taking time before
> the report prints.
> I have been waiting for almost 1 hour for it to complete enhancing
> security..(is this normal?). I restarted the whole process and
> deleted the other .mdw files I had created earlier.
> I hope I can finish it soon.
> Billy
> Joan Wild wrote:
>> You do not create a shortcut on the network.
>>
>> 1. Copy the backend to the server (you've done this).
>> 2. Copy the secure mdw to the server(you've done this).
>> However you said the mdw needed you to import data. Can you describe
>> exactly the messages you received. There is no need to import or do
>> anything to the mdw.
>> Mdw did not show all users as per one-step security wizard report. I
>> believe you said you had multiple mdw files and so likely there is a
>> mix of which one should be used. I suggest you revert to your
>> unsecured database and start over. You need only one secure mdw.
>> Once you have it done, it's that mdw that goes on the server. And
>> it *will* contain all the users you need.
>>
>> Is your database split right now?
>> Yes - Good put the backend on the server. Open the frontend on your
>> PC, and use Tools, Linked Table Manager, and refresh the links; be
>> sure to put a check at the bottom to prompt for location and choose
>> the location of the backend on the server.
>> No - Split the database. See www.jmwild.com/SplitSecure.htm for
>> steps. Put the backend on the server and refresh the links as per
>> the above.
>>
>> If the wizard created a desktop shortcut for you on your PC,
>> right-click it and choose properties. It'll open to the Shortcut
>> tab and the Target line will be selected. The target will take the
>> form similar to: "path to msaccess.exe" "path to secure mdb" /wrkgrp
>> "path to secure mdw" secure mdb will be the original database on
>> your PC - modify it (if necessary) to reflect the path to the
>> frontend on your c: drive.
>> path to secure mdw will be the secure mdw you used to secure your mdb
>> (somewhere on your C: drive) - change the path to reflect the
>> location of the secure mdw on the server.
>>
>> Now, you'll have the backend and secure mdw on the server, a copy of
>> the frontend on your PC, and a shortcut on your desktop.
>>
>> To set up other users you can just copy the frontend from your PC to
>> them. In addition you can copy the shortcut from your desktop to
>> them (a shortcut is just a file with a lnk extension). Ensure that
>> you put the frontend in the same location on their PC as it is in
>> your's OR if you put it in a different location, then modify the
>> shortcut on *their* PC to reflect the location of the frontend i.e.
>> the target would look like: "path to msaccess.exe" "path to
>> frontend" /wrkgrp "path to secure mdw on server"
>> and example:
>> "C:\Program Files\Microsoft Office\Office11\msaccess.exe"
>> "c:\MyApp\frontend.mdb" /wrkgrp "F:\databasefiles\secure.mdw"
>>
>> Just another little wrinkle, but you can use the UNC pathname for
>> the mdw; i.e. \\servername\path\secure.mdw rather than 'F:' drive;
>> this way you don't have to worry about someone having a different
>> drive mapping than you.
>>
>>
>> --
>> Joan Wild
>> Microsoft Access MVP
>>
>> Billy wrote:
>>> Joan,
>>> Your help is great, but would you please provide step by step
>>> process of creating a shortcut on the network as well as securing
>>> the backend and/or frontend.
>>> The secured database is seated on my desktop. I copied it to a
>>> folder in the network..successful, I also copied the mdw file to
>>> the same folder....successful, however, I realised that the mdw
>>> file needed me to import data..(is this normal?). At the same
>>> time, the mdw did not show everybody shown on the one-step security
>>> wizard report...(is this also normal?). If you have some links
>>> like the one you sent yesterday, I would appreciate. I have to
>>> admit that it is the first time I am securing a database on my own.
>>> Thanks for your help so far.
>>> Billy
>>> Joan Wild wrote:
>>>> You need to copy the secure mdw and the mdb to a folder on the
>>>> server that everyone has access to. All users will need
>>>> read/write/create/delete windows permissions on that folder.
>>>>
>>>> You can give each user a desktop shortcut the uses the secure mdw
>>>> and opens the secure mdb. The target would look like:
>>>> "path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure
>>>> mdw"
>>>>
>>>> It is highly recommended that you split the database. Put the
>>>> backend (tables/relationships only) mdb on the server. A copy of
>>>> the frontend (all other objects, and table links to the backend)
>>>> mdb would go on each user's computer. You'd modify the shortcut
>>>> above so that the path to secure mdb would be the path to the
>>>> frontend.
>>>>
>>>> If everyone has Access installed in the same folder, and the
>>>> frontend is installed in the same location on each PC, you can copy
>>>> the shortcut to each person.
>>>>
>>>> Since you've secured it, you shouldn't use the database splitter
>>>> wizard, as that will result in an unsecure backend mdb. Instead
>>>> split it manually.
>>>>
>>>> See www.jmwild.com/SplitSecure.htm
>>>>
>>>>
>>>>
>>>> --
>>>> Joan Wild
>>>> Microsoft Access MVP
>>>>
>>>> Billy wrote:
>>>>> Everything seems to be going well at this point! Now how do I
>>>>> distribute the database to the network or rather how do I create a
>>>>> shortcut that can be accessed by everybody on the common drive?
>>>>> Billy
|
|
Hi, some things that worked for me. The shortcut probably refers to the mdw
file as a switch (/). The workgroup file that is applicable to the database
is therefore loaded when the db is opened. You must however have used or
specified the mdw file during creation. Once Access is passed the mdw file to
use it keeps on using the that one until u specify another one to use
(security settings). If no mdw was specified for the db it uses the default
"blank" privileges that is loaded with Access. If you replace this mdw with
your own then you can not access that db. Solution: copy the "blank" mdw from
another machine and use that for the db. Also delete the mdw switch from the
shortcut target for the db that is not supposed to use the mdw.
Hope this helps.
"jct" wrote:
[Quoted Text] > Sorry for the long post, but I'm hoping to give enough info to get a quick
> resolution. Thanks in advance.
>
> In testing stages of a security on database... I had security set and was
> testing it with another user and myself. The db was on a network server, and
> only one of us could get in at a time. (Hadn't yet taken steps to split db
> into front/back ends.) Her login was working, and I could access through my
> login or through Admin... Not sure what one thing triggered the malfunction
> today.
>
> Someone else, who was trying to help her in my absence, had deleted the db
> shortcut and created a new one. I didn't pay attention to the logon that
> popped up and went through Tools/Security to make sure she was added to the
> database. Turns out it was her server login (used at Start Up) that I added.
>
> Now it appears the security applied to our main system of record (DB#1),
> which is Access based is linked the .mdw of the test database (DB#2).
>
> When she tried logging into DB#1 she was getting a logon prompt, which is
> not required as it is initiated during server login. If I was in either db,
> she couldn't get in either.
>
> I've deleted the .mdw file for the test db, and now we can get in DB#1
> (separate, or at the same time), but neither of us can get in DB#2. I was
> smart enough to save the .mdw file, so it's lost.
>
> How can I fix this mess and salvage the test databse, which now has a lot of
> data in it. The last backup was Many data entry hours ago.
>
> Thank you,
> Janice
|
|
Hi, the reason is that your collegue is not using the same mdw (workgroup)
file as you although you are working on a shared drive. Solution: (1) use a
shortcut with the workgroup switch (/) included in the target; (2) specifiy
the workgroup file to use at your collegue's workstation (subscribe to it) -
this means that the mdw must be available on the network drive (preferably
where the db is located; (3) use th packaging wizard available with Office
Developer to distribute your db as a setup package. The package then includes
the mdw file associated with the db and the setup creates an autmatic link to
it.
A good tip is to always keep a copy of the "blank" system.mdw file that is
loaded with Access. This makes development of a db easier since you can then
subscribe to this workgroup when designing so that you are not required to
log on each time when the db is opened. Later subscribe to the secure mdw for
distribution to other users.
Hope this helps. Rob
"Billy" wrote:
[Quoted Text] > I am working on different Access databases for my company. I am
> expected to provide security features and make sure that the databases
> are running well. There are about 8 databases being used so far, each
> with multiple users.
> I have tried setting up security features on the first database. After
> following the right procedure in User-Security and giving permission to
> users, I went to a collegue's computer to test. She had full access
> and admin privileges. There was no logon prompt.
> This was very disappointing because I thought I followed the procedure
> very carefully.
> We are using a common drive on the network.
> Please help me get this thing done!
> Billy
>
>
|
|
|