Hmm. What if a Word file may be located in more than one location?

S

Sue

I've designed a database & would like to have some step-by-step instructions
for new users available. My thought was to develop a Word document & a
command button to open it. The problem is (please don't laugh - I'm ignorant
about this aspect of things) that my employer has multiple servers. Will a
file placed on one drive - say the "c' drive" - be hit regardless of the
server used?

If you laugh, I'll pout.
 
B

Bob Quintal

I've designed a database & would like to have some step-by-step
instructions for new users available. My thought was to develop a
Word document & a command button to open it. The problem is
(please don't laugh - I'm ignorant about this aspect of things)
that my employer has multiple servers. Will a file placed on one
drive - say the "c' drive" - be hit regardless of the server used?

If you laugh, I'll pout.
Click to expand...

You are going to see that you will have the same problem with the
database (.mdb) file itself in that the file that contains the
tables needs to be accessible to all users who share the data.

Essentially you need to determine which one server will hold the
data tables .mdb (called the back end), and link the forms, reports
and queries (the front end) to that one back end.

You should have a copy of the front end on each user machine's local
hard drive, as this is Microsoft's (and a lot of posters here's)
best practice reccommendation.

Once you establish the architecture for that, you can decide does
the .doc file go in the same directory as the front end or the back
end, Performance issues say the front end, but there can be
exceptions.
 
S

Sue

I understand.
Thanks for the info.

Now other questions as a "sequel" to the last:

1. There is a drive - call it the "h" drive - that all of our group has
access to. This drive can be mapped to the user's account so that the can
access files from any location - we are often mobile & may be at one of any
number of locations in the company. Sometimes when logging on, the system may
hit a different server (depending on how busy the usual one is), but as long
as we've mapped our account to the h:\ drive, we can get there from any
location. Will I achieve what I'm trying for by posting the database on h:\?

2. I want to password-protect the database so that no one can get into it
but members of our group who have been given the password. I assume my next
bit of reading deals with security?

3. I want to further protect the database so that no element of the tables
or queries - and no structure of the database and its reports, forms, and
macros - can be changed unless y me. Again, is reading under the heading of
security my best place to go?

4. is there a particular sequence I should use in performing the above tasks?

Many thanks!
 
M

Mikal via AccessMonster.com

Sue said:
I understand.
Thanks for the info.

Now other questions as a "sequel" to the last:

1. There is a drive - call it the "h" drive - that all of our group has
access to. This drive can be mapped to the user's account so that the can
access files from any location - we are often mobile & may be at one of any
number of locations in the company. Sometimes when logging on, the system may
hit a different server (depending on how busy the usual one is), but as long
as we've mapped our account to the h:\ drive, we can get there from any
location. Will I achieve what I'm trying for by posting the database on h:\?
Click to expand...

All the following assumes you will use Access with the JET database engine
that ships natively with MS Office. If you will be linking Access to a SQL
Server then some of this will not apply.

The short answer is Yes. However, how widespread are your locations? If
they are in the same building you're probably fine. If you are talking about
a WAN, you will need to connect via Terminal Services or via Citrix. If your
WAN is very stable, you may be able to get away with using it, but understand
that you are asking for corruption by doing so and keep good and frequent
backups of the back-end. Here's a really fine resource:
http://www.granite.ab.ca/accsmstr.htm Search for corruption. Keep good and
frequent backups anyway.

Split the database into frontend and backend if you have not already done so.
2. I want to password-protect the database so that no one can get into it
but members of our group who have been given the password. I assume my next
bit of reading deals with security?
Click to expand...

If you password protect the backend you'll have to re-link the tables to the
front end. When you do so, you'll be prompted for the backend password.
After that, you shouldn't have to bother with it again. Access passwords are
not very secure. They will keep out the honest folk and the inept. If you
have highly sensitive information that needs protection from thieves you
likely need more robust security than Access can provide. If you want to
implement User Level Security (Not available in Access 2007) Joan Wild is the
guru: http://www.jmwild.com/AccessTips.htm
3. I want to further protect the database so that no element of the tables
or queries - and no structure of the database and its reports, forms, and
macros - can be changed unless y me. Again, is reading under the heading of
security my best place to go?
Click to expand...

Go to Tools|Database Utilities|Make MDE file. When you do this, make sure
you keep a copy of the original MDB file someplace safe because you won't be
able to modify the Reports and Forms in the MDE file either (I'm not sure
about macros but I don't think so.) Before you do so, uncheck the option to
show the database window under Tools|startup. If you really want to lock
things down, disable the use of bypass keys in the same area. Be careful
here because you can lock yourself out and not be able to get back in. Keep
an unmodified copy of the original MDB file someplace where you can't get to
it till after the panic attack subsides.

Search the granite ab link I gave you above for Tony's Auto FE Updater if you
think you might be needing to change your database from time to time.

If you think you want to disallow the use of bypass keys Albert Kallal has a
good system for toggling it on or off:
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html
4. is there a particular sequence I should use in performing the above tasks?
Click to expand...

I think yours is pretty much on target. and this pretty well exhausts my
knowledge (mainly gleaned from the brighter lights on this forum).

HTH
Mike
 
B

Bob Quintal

I understand.
Thanks for the info.

Now other questions as a "sequel" to the last:

1. There is a drive - call it the "h" drive - that all of our
group has access to. This drive can be mapped to the user's
account so that the can access files from any location - we are
often mobile & may be at one of any number of locations in the
company. Sometimes when logging on, the system may hit a different
server (depending on how busy the usual one is), but as long as
we've mapped our account to the h:\ drive, we can get there from
any location. Will I achieve what I'm trying for by posting the
database on h:\?
yes.

2. I want to password-protect the database so that no one can get
into it but members of our group who have been given the password.
I assume my next bit of reading deals with security?
yes

3. I want to further protect the database so that no element of
the tables or queries - and no structure of the database and its
reports, forms, and macros - can be changed unless y me. Again, is
reading under the heading of security my best place to go?
Click to expand...
that, and splitting the database so that the tables are in one file
(the back end) and the forms, reports and queries are in the other.
(the front end)
4. is there a particular sequence I should use in performing the
above tasks?
Click to expand...
Read and understand about the security first. then read it again..
Then practice implementing it on a copy of the database.
 
Top