Three questions:

I have created a database which will be installed in a new folder in the
root directory of a networked computer. My intention (the recommendation of
the network tech) is to put both the .mdb and .mdw files in that directory
and create a desktop shortcut with a target that will look like this:

"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\New
Folder\Application.mdb"/wrkgrp "C:\New Folder\Application.mdw"

I have tried this on my desktop and it opens fine and asks for the
appropriate user login and database password.

1) Is there anything about a networked situation that would make the target
unlikely to work? I ask this because I tried setting it up before with the
network tech and it didn’t work. I am pretty sure that I had the 3 piece
target correct. He then said that you didn’t need to put the Access.exe piece
in but I found in my testing at home that it would not work without it.
2) I have not yet “secured the database”. Is this something I should do on
the computer I am designing it on or on the destination computer or does it
make any difference?
3) Do I need to "secure it" if I have set up the appropriate
workgroup - i.e. removed Admin from Admins and removed permissions from User
Group?
Thank you for any insight you can give.

Mary S.

"sweeneysmsm" <(E-Mail Removed)> wrote in message
news:8FFA76E3-6102-4430-88AF-(E-Mail Removed)...
>
> "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\New
> Folder\Application.mdb"/wrkgrp "C:\New Folder\Application.mdw"

Do not give the mdb and the mdw the same name. They each need to create a
ldb file.

> 1) Is there anything about a networked situation that would make the
> target
> unlikely to work? I ask this because I tried setting it up before with the
> network tech and it didn't work. I am pretty sure that I had the 3 piece
> target correct. He then said that you didn't need to put the Access.exe
> piece
> in but I found in my testing at home that it would not work without it.

You need the Access.exe piece. In a network environment, you need to ensure
that all users have read/write/create/delete permissions on the folder where
the files are (so that they can create/delete the associated ldb files). In
addition it is adviseable to split the mdb into two (since it's secured,
don't use the database splitter wizard or the backend will end up unsecure -
see http://www.jmwild.com/SplitSecure.htm ) . You put the backend and the
mdw on the server, and give each user a copy of the frontend on their PC,
which will contain the links to the backend. In your shortcut, you can use
UNC pathname for the path to the mdw on the server.

> 2) I have not yet "secured the database". Is this something I should do on
> the computer I am designing it on or on the destination computer or does
> it
> make any difference?

Doesn't make any difference.

> 3) Do I need to "secure it" if I have set up the appropriate
> workgroup - i.e. removed Admin from Admins and removed permissions from
> User
> Group?

I don't understand. Do you mean you just modified your existing system.mdw?
If so, then it isn't secure at all. The first step is to create a new
workgroup file. See
http://www.jmwild.com/Accesssecurity.htm


--
Joan Wild
Microsoft Access MVP

"Joan Wild" wrote:

> > 3) Do I need to "secure it" if I have set up the appropriate
> > workgroup - i.e. removed Admin from Admins and removed permissions from
> > User
> > Group?
>
> I don't understand. Do you mean you just modified your existing system.mdw?
> If so, then it isn't secure at all. The first step is to create a new
> workgroup file. See
> http://www.jmwild.com/Accesssecurity.htm
>
>
> --
> Joan Wild
> Microsoft Access MVP

I did set up a new workgroup and have removed Admin from the Admins group in
the new workgroup and removed all permissions the User group. I have added
myself and another person to the Admins group and created another Group which
will have permissions for those with Access to use the database. Having done
this, do I need to "Secure" the database. Can I just manage safely wiht the
..mdb and .,mdw files?

I imagine that I will also need to go into the System file and add another
person to the Admins group and delete the Admin from the Admins group and
create another User group with a different name and delete the permissions
for the existing User group. I guess my understanding is that if we didn't do
this anyone who could open another database in Access using the original
System file would as a member of the User group be able to access my database
if they knew the database password. Is that correct?

Also all of the users will be using the database from the one computer. If
that is the case, is it necessary/advisable to put it on the server? If they
were just using their own computer they wouldn't have a server.

Thank you for your previous comments. What does UNC pathname mean?

Mary S.

Further to what Joan said about splitting your db into a so-called
"front end/back end" structure.

Be aware that there are some logistic and technical problems that you
may have to solve, to implement that (recommended) structure. For
example, how to update the FE on the user pc's, when you develop a new
version of the FE. Or maybe give each user a seperate copy of the FE
/on the server/.

IOW it takes some effort to do the split thing. You may need to plan
for that effort.

HTH,
TC

"sweeneysmsm" <(E-Mail Removed)> wrote in message
news2ECA9D0-4973-4CD6-AE17-(E-Mail Removed)...

> I did set up a new workgroup and have removed Admin from the Admins group
> in
> the new workgroup and removed all permissions the User group. I have added
> myself and another person to the Admins group and created another Group
> which
> will have permissions for those with Access to use the database. Having
> done
> this, do I need to "Secure" the database. Can I just manage safely wiht
> the
> .mdb and .,mdw files?

What you have done is secured the database, so I still don't understand what
you mean.

> I imagine that I will also need to go into the System file and add another
> person to the Admins group and delete the Admin from the Admins group and
> create another User group with a different name and delete the permissions
> for the existing User group. I guess my understanding is that if we didn't
> do
> this anyone who could open another database in Access using the original
> System file would as a member of the User group be able to access my
> database
> if they knew the database password. Is that correct?

No it isn't. You removed all the permissions for the Users Group. That
group is common to all mdw files. So if they open it using the original
system.mdw, then they won't be able to do anything - they'll be silently
logging in as Admin which is a member of the Users Group and it doesn't have
any permissions.

> Also all of the users will be using the database from the one computer. If
> that is the case, is it necessary/advisable to put it on the server?

Not in that case, however you need to ensure you back it up - more likely to
be done if it's on a server.

> What does UNC pathname mean?

Universal Naming Convention
\\servername\share instead of mapping it to G: or whatever.


--
Joan Wild
Microsoft Access MVP

"Joan Wild" wrote:

> "sweeneysmsm" <(E-Mail Removed)> wrote in message
> news2ECA9D0-4973-4CD6-AE17-(E-Mail Removed)...
>
> > I did set up a new workgroup and have removed Admin from the Admins group
> > in
> > the new workgroup and removed all permissions the User group. I have added
> > myself and another person to the Admins group and created another Group
> > which
> > will have permissions for those with Access to use the database. Having
> > done
> > this, do I need to "Secure" the database. Can I just manage safely wiht
> > the
> > .mdb and .,mdw files?
>
> What you have done is secured the database, so I still don't understand what
> you mean.


By secure the database I meant to go through the process of splitting the
database into a front and back end - I believe that at the end of it the .mdb
file is retitled "Secure whatever it was.mdb" - at least that is what I
remember from the last time I did it. Judging from TC's comments and yours
that probably is a path I had best avoid.
>
> > I imagine that I will also need to go into the System file and add another
> > person to the Admins group and delete the Admin from the Admins group and
> > create another User group with a different name and delete the permissions
> > for the existing User group. I guess my understanding is that if we didn't
> > do
> > this anyone who could open another database in Access using the original
> > System file would as a member of the User group be able to access my
> > database
> > if they knew the database password. Is that correct?
>
> No it isn't. You removed all the permissions for the Users Group. That
> group is common to all mdw files. So if they open it using the original
> system.mdw, then they won't be able to do anything - they'll be silently
> logging in as Admin which is a member of the Users Group and it doesn't have
> any permissions.
>

Joan, I experimented with this and it didn't work for me. Is there something
I am missing? I set up a workgroup specifically for the database and included
it as the 3rd piece in the Target in the desktop shorcut. In that worgroup I
removed Admin from the Admins group and put in a new person. I removed all
permissions from the User group in that same workgroup. I password protected
the database but have not yet added login passwords.

I exited the database and opened another database using the ordinary
System.mdw. I closed that other database but remained in the Access window. I
then went and opened the database that I am trying to secure. All it asked me
for was the database password. I then got into everything since Admin (the
silent user) has user access to all in the system.mdw. That is why I asked
you if I needed to go into the System.mdw and add in another Admin and remove
the permissions from the User group. I understood you to have said "no". That
doesn't seem a satisfactory solution in that someone would only need to
rename the System file and I think a new one with all of the default
permissions would be created.

I feel that there is something I am missing.

Thanks so much for your cautions. I think that I will probably not go with
the "split route" since the users will in fact be accessing the .mdb from one
computer. If I can sort the final issue out so that anyone trying to get in
from the System.mdw can't pull it off I will be more than happy. That is my
last hurdle.

Mary

"TC" wrote:

> Further to what Joan said about splitting your db into a so-called
> "front end/back end" structure.
>
> Be aware that there are some logistic and technical problems that you
> may have to solve, to implement that (recommended) structure. For
> example, how to update the FE on the user pc's, when you develop a new
> version of the FE. Or maybe give each user a seperate copy of the FE
> /on the server/.
>
> IOW it takes some effort to do the split thing. You may need to plan
> for that effort.
>
> HTH,
> TC
>
>

(snip)

> > > do I need to "Secure" the database. Can I just manage safely wiht the
> > > .mdb and .,mdw files?
> >
> > What you have done is secured the database, so I still don't understand what
> > you mean.
>
>
> By secure the database I meant to go through the process of splitting the
> database into a front and back end


No, those are two different things. "Securing" a database is the
process of creating a new workgroup file, removing Admin from the
Admins group, etc. etc. etc. "Splitting" a database is the process of
splitting it into a front-end part containing the forms, reports etc.,
and a back-end part containing just the tables.

A database can be secured but not split; split but not secured; secured
*and* split; or neither split nor secured.

HTH,
TC

>> "Joan Wild" wrote:
>>
>
>
> TC set you straight on splitting/securing not being the same thing.
>
>
>> Joan, I experimented with this and it didn't work for me. Is there
>> something
>> I am missing?
>
> I would say so. If you follow all the steps exactly, then they won't
> be able to even open the mdb without using your secure workgroup
> file. My guess is that the Admin user still owns everything. In
> order to get the login prompt, you need to assign the Admin user a
> password - that will cause it to appear. Then open Access using your
> secure mdw and log in as that user you added to the Admins Group.
>
> Create a new mdb and import all the objects from your database (I
> think this may be the step you missed). This will ensure that Admin
> doesn't own everything. Then proceed to remove permissions for Users
> Group...etc.
>
> It is critical that you follow every step. See
> www.jmwild.com/AccessSecurity.htm

Light finally dawned on marblehead.

I knew that I had followed all of the steps. I knew that the database did
not belong to the "Admin" user. The problem was that after I had opened a
blank database using the new workgroup with the new Admin as owner and
imported all of the objects I used the old database to test. Obviously not
going to work. I discovered it when I checked on the database ownership.

Thank you so much for your patience with me. The process has been tedious
but I feel a whole lot more confident with it.

Mary

"Joan Wild" wrote:

> >> "Joan Wild" wrote:
> >>
> >
> >
> > TC set you straight on splitting/securing not being the same thing.
> >
> >
> >> Joan, I experimented with this and it didn't work for me. Is there
> >> something
> >> I am missing?
> >
> > I would say so. If you follow all the steps exactly, then they won't
> > be able to even open the mdb without using your secure workgroup
> > file. My guess is that the Admin user still owns everything. In
> > order to get the login prompt, you need to assign the Admin user a
> > password - that will cause it to appear. Then open Access using your
> > secure mdw and log in as that user you added to the Admins Group.
> >
> > Create a new mdb and import all the objects from your database (I
> > think this may be the step you missed). This will ensure that Admin
> > doesn't own everything. Then proceed to remove permissions for Users
> > Group...etc.
> >
> > It is critical that you follow every step. See
> > www.jmwild.com/AccessSecurity.htm
>
>
>