security troubleshooting

[_]

So I have followed the Step by Step instructions provided and still need
help. The final step creates a shortcut on my desktop. But I need to create
a shortcut on the shared drive (fyi - the .mdw and database files all are - i
put everything on the shared drive) so other users can access it.

When they open the .mdw security file none of the tables or reports appear
so I know it's not that one to open.

So they try opening the original .mdb database and an error message appears
stating "You do not have the necessary permissions to use the...object..."
Now could it be that my shared drive happens to be L: and others can
have their shared drive R: or whatever the case may be. I am really at a
loss right now as I have been trying to tackle security for over a week!
I've done the step by step and read the document posted on
www.geocites.com/jacksonmacd...please help.

 

[Joan Wild]

Hi _,

So I have followed the Step by Step instructions provided and still need
help. The final step creates a shortcut on my desktop. But I need to
create
a shortcut on the shared drive (fyi - the .mdw and database files all
are - i
put everything on the shared drive) so other users can access it.

You should reconsider this. You will likely corrupt the database having
everyone use the same mdb on the server. You should split the database,
putting the backend on the server, and giving each user a copy of the
frontend on their workstation, linked to the backend on the server.

So they try opening the original .mdb database and an error message
appears
stating "You do not have the necessary permissions to use the...object..."

They need a shortcut to open the mdb file (as it is, they are using their
default system.mdw, which correctly does not give them permission to use the
secure mdb).

Now could it be that my shared drive happens to be L: and others can
have their shared drive R: or whatever the case may be.

Yes. Right-click your shortcut and choose properties. Change the
references to the mapped drive to the UNC pathname instead. Then you won't
need to worry about drive mappings:

\\servername\share\...\..\filename.mdb instead of L:\path\filename.mdb

Give each user a copy of the shortcut.

 

[_]

There are several hundred users that will need to access the database. So
are you saying I can just put that shortcut on the Shared drive and any user
will be able to access it? I have to admit I am slightly confused on the
shortcut you recommended (I'm not that technical savy). Also, can I just
leave the shortcut on the shared drive and move the other files to my
hardrive? I have briefly read about front end and back end splitting and
hoping to just solve this first but will re-evaluate.

 

[Joan Wild]

There are several hundred users that will need to access the
database. So are you saying I can just put that shortcut on the
Shared drive and any user will be able to access it? I have to admit
I am slightly confused on the shortcut you recommended (I'm not that
technical savy). Also, can I just leave the shortcut on the shared
drive and move the other files to my hardrive? I have briefly read
about front end and back end splitting and hoping to just solve this
first but will re-evaluate.

If all the users have Access installed to the same folder you can create a
shortcut with a target of
"c:\path to msaccess.exe" "path to mdb" /wrkgrp "path to mdw"
The paths to the mdb and mdw can use UNC naming. Then just email the
shortcut to everyone and tell them to copy it to their desktop.

You really should split it with that many users.

 

[_]

Joan,
I took your advice and did the database splitter under Tools and Database
Utilites. I saved this to my desktop - what is the process now for securing
it? I am confused b/c now I have the original database on my desktop and the
split one located there (I want to avoid putting the database on the server
until I secure it). What is the function of one vs. the other? If there are
any other step by step instructions out there please let me know as I will
try again. Thanks I truly appreciate your patience (I am frustrated with
myself as well)

 

[Joan Wild]

Joan,
I took your advice and did the database splitter under Tools and
Database Utilites. I saved this to my desktop - what is the process
now for securing it?

Oops, sorry I should have pointed you to the following site. You shouldn't
use the database splitter on a secure database, as the backend will end up
totally unsecure. Instead, split it manually. Go back to your original
database and follow the steps at
http://www.jmwild.com/SplitSecure.htm

At step 1, put the copy of the database on the server(this will be the
backend). When you do the linking at step 4, use Network neighborhood to
locate the backend (that will use UNC pathnames for the links).

 

[_]

Here is where I am at. When it says open the original database I assume this
is the one ending in .mdb and Not .mdw. Correct? So I deleted the
tables/relationships (which happened to delete the reports and queries as
well - is that correct). However, when I go to step 4 and go through the
network neighborhood as you suggested I can't find the backend database (it
shows no file to link) - but when I go out through my shortcut on my desktop
I see it on the server. Any ideas? Thanks again as I think I am finally
getting close to the end!

 

[Joan Wild]

Here is where I am at. When it says open the original database I
assume this is the one ending in .mdb and Not .mdw. Correct?

Yes

So I

deleted the tables/relationships (which happened to delete the
reports and queries as well - is that correct).

No, just delete the tables/relationships. That would not delete the
reports/queries.

However, when I go

to step 4 and go through the network neighborhood as you suggested I
can't find the backend database (it shows no file to link) - but when
I go out through my shortcut on my desktop I see it on the server.

I don't understand. If you open network neighborhood, you can navigate
through the server, folders to the backend location (you did put a copy of
it on the server, right?)

 

[_]

Okay one last question I guess. When I am told to go back to the original
database it says I don't have permissions to open...no prompt for password or
anything. This is step by step but apparently I am missing something.

 

[_]

Here is my target line (but it won't fit - it's too long - is there a limit?)
and do you see anything wrong with what I have entered? Any suggestions.

"C:\Program Files\Microsoft
Office\OFFICE11\MSACCESS.EXE"\\Corp.global.level3.com\dfs01\ssidata\ssiamfile1\data\DeptShares\SalesOps\contracts_database\Access
Database\CD 4-21-05.mdb
/WRKGRP\\Corp.global.level3.com\dfs01\ssidata\ssiamfile1\data\DeptShares\SalesOps\contracts_database\Access Database\Wrkgrp File.mdwâ€

 

[Joan Wild]

Here is my target line (but it won't fit - it's too long - is there a
limit?)
and do you see anything wrong with what I have entered? Any
suggestions.

You are missing some quotes and some spaces. It is faily long too - you may
have performance issues with the mdb buried so far down the tree. If you've
split the database, then you should put the frontend on the local computer,
with table links to the backend on the server (the shortcut wouldn't include
the backend mdb path).

"c:\Program Files\Microsoft
Office\Office11\msaccess.exe"<sp>"c:\somewhere\frontend.mdb"<sp>/wrkgrp<sp>"path
to mdw on server"

 

[Joan Wild]

Okay one last question I guess. When I am told to go back to the
original database it says I don't have permissions to open...no
prompt for password or anything. This is step by step but apparently
I am missing something.

That's because you are joined to the standard system.mdw by default. Either
join your secure mdb using the workgroup administrator in the security menu,
or better create a shortcut that uses the correct mdw for that session:
"C:\Program Files\Microsoft Office\Office11\msaccess.exe" /wrkgrp "path to
mdw"

Then use the shortcut and once Access opens, open your mdb - it will prompt
you then.

 

[_]

I got the path name and everything work right for me!!! - however, when my
coworker logs on this is the message it states "Microsoft Access can't find
the database file D:\DB Secured Files\Contracts DB.mdb" - I checked and it
is out there. Why can't they access it? Just when I think I've got a grip
on it - something else doesn't work.

Here is what I did. I put the shortcut that was originally created on the
desktop onto the server and changed the path name to this (as your previous
suggestion stated the shortcut wouldn't include the backend mdb path)

"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "D:\DB Secured
Files\Contracts DB.mdb" /WRKGRP
"\\Corp.global.level3.com\dfs01\ssidata\ssiamfile1\data\DeptShares\SalesOps\contracts_database\Access Database\Security Wrkgrp.mdw"

 

[Joan Wild]

I got the path name and everything work right for me!!! - however,
when my
coworker logs on this is the message it states "Microsoft Access
can't find
the database file D:\DB Secured Files\Contracts DB.mdb" - I checked
and it
is out there. Why can't they access it?

Perhaps their D: drive is mapped to something different, or they don't have
windows permissions on the D:\DB secured Files folder.

 

[_]

Earlier you stated "If you've split the database, then you should put the
frontend on the local computer, with table links to the backend on the server
(the shortcut wouldn't include the backend mdb path)." So if I put the
frontend on the local computer then nobody would be able to access the
shortcut to the database (on the server) b/c it would require them to access
my hardrive? And my other problem is the target line won't accept the path
b/c it's too long. Any other suggestions?

 

[Joan Wild]

Earlier you stated "If you've split the database, then you should put
the frontend on the local computer, with table links to the backend
on the server (the shortcut wouldn't include the backend mdb path)."
So if I put the frontend on the local computer then nobody would be
able to access the shortcut to the database (on the server) b/c it
would require them to access my hardrive?

Sorry, I don't follow that. Why do they need access to your hard drive?
The backend is on the server. The mdw is on the server. The frontend is on
their PC. The shortcut is on their PC. If everyone has Access installed to
the same folder, and if they all put the frontend in the same folder on
their PC, you can create a dekstop shortcut, and either email it to them, or
put it somewhere they can copy it from (like the server where the backend
is). All the users will need create/read/modify/delete permissions on the
folder on the server.

And my other problem is

the target line won't accept the path b/c it's too long. Any other
suggestions?

Make it shorter. I don't mean that as being smart*ss, but can you put the
frontend in a folder close to the root on their PC? Maybe c:\abc\abc.mdb.
That will go a long way to making it shorter. Also can you move the mdw and
backend higher up the tree?

I don't see anyway around this.

 

[_]

I guess I didn't realize each user would have to go through that trouble of
putting the frontend on their D drive. I was trying to avoid having people
to follow any steps (as there are too many people/locations). So really I
have to find a shorter target line to put the frontend on the server. Then
they wouldn't have to create a folder on the D drive or copy the frontend on
their pc. If I put the frontend on the server then I would just email them
the shortuct - correct. I guess the step on how to get people to access it
with the login information (the last step) is what I have been having trouble
comprehending. We want to keep it simple for people to access.

 

[Rick Brandt]

I guess I didn't realize each user would have to go through that
trouble of putting the frontend on their D drive. I was trying to
avoid having people to follow any steps (as there are too many
people/locations). So really I have to find a shorter target line to
put the frontend on the server. Then they wouldn't have to create a
folder on the D drive or copy the frontend on their pc. If I put the
frontend on the server then I would just email them the shortuct -
correct. I guess the step on how to get people to access it with the
login information (the last step) is what I have been having trouble
comprehending. We want to keep it simple for people to access.

If you have multiple people opening a common front end file on the server it
WILL end up corrupted.

There are methods to make distributing and updating of front end files on
the users local drive completely automatic.

 

[Joan Wild]

I guess I didn't realize each user would have to go through that
trouble of putting the frontend on their D drive. I was trying to
avoid having people to follow any steps (as there are too many
people/locations). So really I have to find a shorter target line to
put the frontend on the server. Then they wouldn't have to create a
folder on the D drive or copy the frontend on their pc. If I put the
frontend on the server then I would just email them the shortuct -
correct. I guess the step on how to get people to access it with the
login information (the last step) is what I have been having trouble
comprehending. We want to keep it simple for people to access.

Initial installation always requires some setup. Perhaps you could use an
installer program that installs the frontend and creates the desktop
shortcut. All they need to do is open the installer program (is that too
much for them?). Something like
http://www.dev4pc.com/setup2go.html

You might want to investigate some method of updating their frontends when
you have changes you've made. You definitely do not want to have everyone
sharing the frontend on the server. Have a look at
http://www.granite.ab.ca/access/autofe.htm

 

[_]

I finally got it to work with the login prompting my other co-workers. Down
to the last questions. The frontend is on the server (which you all have
advised against doing so I will re-evaluate). Now the original, backend, and
frontend are on the server. I have my team that can make edits and others
that can read only. My question is when my team is making changes should
they update the original database (and will that update the frontend)? Or
should they update the frontend (and will that update the original)?