Sharing Access Databases

This document is meant to provide the best practices for sharing an access database with
others. Incorporated into these best practices are the concepts of Performance, Maximum
Security, Future Manageability, and Higher Degrees of Scalability. Simply put, your database will
be as secure as possible, as easy to modify as possible, and as easy to migrate to a larger
platform when and if you ever outgrow Access.

A common mistake is to share an access database by saving it to a network share

and control access via NTFS ie. Read Only or Full Access permissions.

If you fail to give a database user less than "Full Control" permissions on the directory which
contains the database. This will cause problems each time they go into the database as they
can't lock the records in the database, due to the inability to manipulate the locking database file
(*.LDB).

What Is An LDB File ?

Whenever you open an Access database, a file with the same name as the database and an
extension of LDB will be opened automatically.

For example if you open Northwind.mdb, a file called Northwind.ldb will be generated. This new
file keeps track of users and the objects that require some form of locking in the database.
When all users have exited gracefully from the database, the LDB file is automatically closed
down and deleted.

When a user says, "I can't get into the database. The message says, 'The file is already in use,'"
explain to your boss, "That's because the first user to open the database didn't have 'create'
permissions to create the locking database file, because I didn't give them 'Full Control'
permissions on the directory that contains the database.

All database users must have "Full Control" permissions on the directory which
contains the database.

Sharing an entire database over the network has been identified by Microsoft as the
number one cause of database corruption, so don't do it!

Congratulations! Your database has become so popular that others would like to use it. Just
copy it to a shared location on the network and create shortcuts, right? Wrong! This is perhaps
the largest cause of Access database corruption. Multiple users accessing the same .MDB at
the same time is just asking for problems.
What is the correct method to share an Access database?

The correct method to share an Access database is to split the database into a frontend
(FE) and backend (BE).

Splitting a database is a relatively simple concept. You take an existing Access MDB database
with its tables, queries, forms, reports, macros, modules, etc. and divide it into two databases:

• The “BackEnd” database just contains the tables

• The “FrontEnd” database contains the application objects (everything except the tables)
and links to the tables in the back-end database

A copy of the FE database should be installed on each user's local hard drive.
The BE database, which contains only the shared tables, is located on the network. Think of the
FE like a shortcut on the users desktop that points to the BE on the server that contains the
data.

This design is especially useful in multi-user environments where the back-end database is
stored on a network and contains the shared data. Each user then has a copy of the front-end
database on their desktop pointing to the shared database.

In multi-user environments, the front-end database can also contain tables that are private to the
user. These local tables can store the user’s settings, selections, temporary or intermediate
tables for processing data or reports, etc.
Reasons to Split a Microsoft Access Database

Here are some of the major reasons to use a split database architecture

• Without a split database architecture, you’ll need to update the database with the latest
data, people have changed with every new release.
• Application enhancements are simplified since they are made in the front-end database
without worrying about changes to the data in the back-end database. Releasing new
versions and bug fixes becomes much easier since only the application part needs to be
distributed. Of course, if you modify table structures or add/delete/rename tables, you’ll
need to apply those changes to the back-end database.
• Performance can be significantly enhanced and network traffic reduced when the user
has a copy of the front-end database installed on their desktop rather than running it off
the network each time they use it.
• Temporary tables can be kept for each user in their front-end database. This avoids
collisions among multiple simultaneous users if they were all using one database.
• Without splitting a database, multiple users running the same database on the network
increase the chance of database corruption. The split database design minimizes this
problem and avoids code corruption from impacting data corruption.
• This simplifies database administration since the data is stored centrally and can be
backed up and compacted. A single master front-end application database is copied to
each user’s machine, but is not necessary to back up.
• Provides an opportunity to expand a database size beyond the 2 GB size limitation of
Access since the front-end database can link to multiple back-end databases if
necessary.
• Sets the stage for migration to SQL Server. If the application evolves to need the
features of SQL Server, you can still use the front-end database to link to data stored in
SQL Server.

Optimise Performance

Most Access multi-user applications involve a database that is accessed simultaneously by

different users and applications.

The data contained in this database can be described as dynamic meaning that in a networked
environment the data changes as users add new records or edit them.

However, the components and objects of your Access application – forms, reports, queries etc -
are static. In majority of cases these database objects are stored in a central database and each
time a user accesses this application they receive these static objects together with the dynamic
data. Receiving and sending the same static data over the network again and again will of
course affect the performance of the application negatively especially as more and more users
make use of your application. An obvious solution to this scenario would be to use the network
to only send dynamic data and at the same time enable users to load the forms, queries etc.
locally.
How do I split a database?

*** Always backup any database before making changes of any kind. ***

Using Microsoft Access Splitter Utility

Beware splitting a secure database with the wizard -- The Database Splitter Wizard is
commonly used to quickly and easily split the database, but if it's used on a secure database,
the back end database file will be left unsecured.

Microsoft Access has a built-in utility for assisting you with the splitting process.
Open Access > Choose Tools > Database Utilities > Database Splitter

The Database Splitter dialog box

Creating the Back-end Database

Confirmation of Database Split

You will now have a backend and frontend copies of your database.
The two copies of your database will be distinct in the sense that all tables will be saved to the
backend copy while most other objects such as forms, reports, macros etc will be placed in the
front end copy.

Note also that the frontend copy of your database will not have any tables in it; this is indicated
by the little black arrow icon that appears next to the table names in the tables window. They will
have links to the tables that is now stored in the backend copy of your database:
Displaying the database FrontEnd

The Database Splitter Tool provides the same functionality as splitting the database manually as
described below.

Splitting an Access Database manually

Create the BackEnd (Where the Tables will reside)

1. Make a copy of your database - This will be the backend.

2. Open the backend and delete all objects except the tables.

So delete queries, reports, forms etc…

What do I do with the BackEnd?

The BE should reside permanently on your network share.

Note: This new BE should be named differently than your FE.

Example:

FE name = Accounting.MDB, BE name = AccountingBE.MDB

All of your users will need Read/Write/Delete permissions at the BE location.

Create the FrontEnd

1. Open your original database and delete the tables/relationships.

To DeleteTables/Relationships

Goto Tools > Relationships

If a relationship is established you will see a line connecting fields in the Relationships
window as shown

You now have a basic FE.

What do I do with the FE?

This new .MDB file becomes your new development copy. Guard it with your life. Back it up
frequently, as well as the new BE you have created which houses all of your data. Design
changes from now on will take place in this FE copy.
Link the FE to theBE

Open the FE and link to the tables in your newly created BE Go to File, Get External Data, Link
Tables and locate the backend in its permanent network location.

Choose all the tables > Choose OK. Choose File > Get External Data > Link Tables >
Browse to your BE and link.

(If you change the BE location after the links in your FE are created, they will be broken and
you will have to relink them.)

So how would you update the links?

Well Microsoft Access provides us with the Linked Table Manager, which as the name implies,
manages links between tables. To access the linked table manager, simply right click on the
linked table and select Linked Table Manager from the list:
The Linked Table Manager

The dialog box lists the linked tables in the current database and shows the location of the
physical tables to which they point. You can select the links that you'd like to update, and then
click the OK button. Access will then display a File Open dialog box that prompts you for the new
location of the back-end database file.

Distribute individual copies of this new FE to your users.

"Can I use a shortcut on my user’s desktop to open the FE?"

A: Yes. But the shortcut should point to the LOCAL COPY of the FE.

Each user receives their own copy of the FE file this copy should be placed on their
local machine.

Splitting databases as above is a fantastic way of solving the network ‘bottleneck’ problem the
only drawbacks is that every time you make a change to any of the objects contained in the front
endpart of your application you need to redistribute that copy to all your users. If you only have
one or two users, this is not a problem; if you have a few hundred users then it just might
become one!

There are many good reference articles for redistributing a FE database automatically without
going machine to machine. Here are a couple of the many links you will find if you do a search:

Deploying and updating Front End Database Applications, by Bill Mosca

http://thatlldoit.com/howtosarticles.aspx#fe_updater

Auto FE Updater, by Tony Toews

http://autofeupdater.com/
Securing and Administering Access

So now we have split the Access database into a frontend (FE) and backend (BE).
How do we share the database and control access with Read Only or Full Access permissions?

MS Access Security

User-level security Governing who is permitted to view, add, edit and delete database objects
(tables, queries etc)

And Workgroup-file-based security: Controls the ability to edit user permissions

Before we begin, we first need to define some terms.

A Workgroup Information File (*.MDW) stores information to authenticate a user. It stores the
user names, group names, and passwords. It does not store any permission or rights to any
database. Its main purpose is to verify that a user is really who they say they are. The
permissions of the database objects, tables, queries, forms, etc., are stored in each MDB file.
The

System.mdw is the default workgroup filename created when you install MS Access.

When you create a new User, you will be prompted for a User Name, Password, and a PID or
Personal Identification number. A PID can be any text or numbers up to 20 characters long. All
three values uniquely identify each user.

Every time a user opens the MS Access program, MS Access attempts to login the Admin user
with a blank password. If the log in is successful, MS Access continues loading and the user
never realizes that they were logged in as Admin. However, if the login is unsuccessful, say for
example the Admin user does not have a blank password, then a login dialog box pops up
asking the user to specify a username and password.

MS Access verifies that the user name and password exist in the Workgroup Information File.
After the user has been verified, the workgroup information file’s job is done. The MDB itself
stores security rights and privileges for each user and for each database object

The MDB will have a list of user id’s and the privileges that each user may have. One user may
have the rights to open the table, but not delete any records, or change the design of the table.
Another user may not have any restrictions at all. The MDB file knows each user’s privileges.
The distinction between the workgroup information file and the MDB file is one that confuses a
lot of developers.
Secure the Database with the User-Level Security Wizard

The User-Level Security Wizard can secure any or all of the objects in your database. All the
relationships and linked tables are kept intact when you secure the database with the Security
Wizard. It also makes a backup copy of the original database in case you have forgotten to do
so. The backup file has the same name with the .bak file extension.

With the Security Wizard, you can be specific about which users enjoy which permissions. You
can also decide who belongs to which groups and edit user passwords and personal IDs (PIDs)
as well. A PID is similar to a password and is used in combination with the user name to identify
an account.

Start the User-Level Security Wizard

The database must be open before you can work with the User-Level Security Wizard.

TIP Prior to using the Security Wizard, be sure to open the database in shared mode. If you
open it in Exclusive mode, the Security Wizard will offer to reopen it in shared mode.

The first thing that you need to do when intending to use a Microsoft Access database in a
shared environment is to put it in shared mode. You can do this by selecting Tools > Options,
which opens the Options dialog box:

Click on the Advanced tab Default Open Mode selection box and check the ‘shared’ option as
above. This will then open all databases in shared mode by default. This means that you don’t
have to go through this exercise every time you create/open a new database.
Also note Default Record Locking selection options

• No Locks - When a user has saved the changes to a record that has been edited, then
and only then does Microsoft Access lock it. The record is therefore not locked while the
user is actually editing it. The No Locks option is best used when there is a slim chance
of more than one user editing the same record. This method of locking is also referred to
as optimistic locking.
• All Records - As the name suggest, this option locks up the entire table while records
are being edited. Of all the options, this one is the safest for obvious reasons. The
disadvantage of this method of record locking is that multiple users will be unable to
access the database for long periods of time.
• Edit Record - This option is the most logical and I think the most commonly used in a
multi-user environment. The Edit record option ensures that Access locks a record the
moment a user begins the editing process and then the lock is released when the user
saves or otherwise abandon the edits. This method of locking is also referred to as
pessimistic locking.

Select the most appropaite option i.e. Edit Record

1. Open the database whose objects you want to secure.

2. Click Tools > Security > User-Level Security Wizard.

The wizard will immediately ask you to create a workgroup information file. It will create an
unsecure backup of the database, and then move to secure the current database. You will need
to put in information about the users who will develop and use the database.

Create a new workgroup information file (*. MDW)

Use the MS Access Workgroup Administrator program. The WRKGADM.EXE file starts this
program. Do not leave the Workgroup ID blank or anyone will be able to create a workgroup file
similar to yours.
The default workgroup file is called System.MDW. In earlier versions of Access, system.mdw
was located in:

c:\windows\system\ or in more recent versions in:

C:\Documents and Settings\[user]\Application Data\Microsoft\Access

Note that this recent setup makes the default workgroup file particular to the user logged in

You should rename the workgroup file system.mdw it should have a different name to avoid
confusion. Also avoid names that conflict with your database names. Access won’t run properly
if the workgroup name (MDW file) and the database name (MDB file) are identical.

The Security Wizard opens and asks you to

Select Create A New Workgroup Information File if one doesn’t exist.

Select Modify My Current Workgroup Information File to make changes in an existing WIF

Select Create A New Workgroup Information File Click Next

A workgroup information file is a file about the users in a workgroup. Microsoft Access reads this
file at startup. It contains information about account names, passwords, group membership and
preferences. Preference information is specified in the Options dialog box.

A workgroup information file is initially created by the setup program when Microsoft Access is
installed. The file is identified by the name and organisation information that is supplied during
the setup process of Microsoft Access.

A Workgroup ID (WID) is created when a new workgroup information file is created. A WID can
have between four and twenty characters and is case-sensitive. The WID guarantees that the
workgroup file can't be recreated by another user by simply guessing the name and company. It
also makes the Admins group unique to this workgroup file.

By default, Access will create a unique, 4 to 20 character string at random that is case sensitive,
and associates an identity to the workgroup, otherwise refered to as a WID. For security
purposes the WID is hidden here.

If you are creating a database for several users to user on a network, you will want to put
both the MDW and the MDB file on the network for all persons to use. Everyone must join
the new MDW to be authenticated properly. Otherwise, the MDB file will not allow them to
access any objects.

In File name select afile name and its Network Location

Remember rename the workgroup file called System.mdw avoid names that conflict with your
database names. Access won’t run properly if the workgroup name (MDW file) and the database
name (MDB file) are identical.
 If you choose to make the WIF the default, every Access database you open will use it
unless you specify that it be opened with a different WIF.

Ensure that the "I want to create a shortcut to open my secured database" option is selected,
before clicking Next.

The wizard then will ask you what objects in your database do you want to secure. By default,
Access will secure all existing database objects and all new objects. You can select objects that
will not be secured, meaning ALL users will have full permissions for that object. It's
recommended that you don't bypass security for any object within your database.

Click Next

Naturally, you don't want everyone to have Admin rights to a database. The next screen allows
you to include pre-defined groups within your workgroup. If you click on each group (do not put a
checkmark beside any yet), you can read a brief description of each group. To make it easier to
track, it's recommended that you change the Group ID of any groups you include to something
easier to work with.

Create any group accounts for this workgroup.

For example, you may want to create a group named PowerUsers for users that may need lots
of database permissions. You may also create a Personnel group account for those users that
only need limited rights.
To make permissions easier for you to manage, try and avoid setting permissions for individual
users.

Remember that there are several database object types for which you may need to set
permissions.

Database object, Table objects, Query objects, Form objects, Report objects, Macro objects,
Module objects

Pre-Defined Groups

Click Next, once you have the groups you want.

In addition to these available groups, Access creates two other groups, Users and Admins.
By default, all database users are added into the Users group. Those users who are in the
Admins group have full permissions and are the only users that can create permissions and
groups. For this exercise, the "No, the Users group should not have any permissions" option will
be selected.
Enter a password and change the personal ID (PID) for the Administrator account before
you add any users to your database.

All the databases that you have been creating up to this time have been created by the Admin
user of the default System.Mdw. The System.Mdw that comes with Access is a generic
workgroup file. All System.Mdw on everyone’s computers has the exact same Admin account
with no password and with a PID of Null, making the Admin user account not very secure to
continue to use.

When entering passwords, they are shown in plain text for all to see.

Create a new user account that will be the new workgroup administrator. Click Next

Instead of continuing to use the Admin user, we will disable the Admin user's abilities. The
reason for this is that every workgroup file has an Admin user, so using it will make our database
less secure. I like to name my new workgroup administrator something like PowerAdmin. Write
down the new name and PID. Store this information in a secure location.
Now you will need to assign your users to groups. By default, the Admins group will be present.
If specified that the Users group shouldn't have permissions, then the Users group will not be
present.

Modify the Admins group by adding the new administrator and removing the original Admin
account.

Any user in the Admins group will have full control of all the database's objects. They can also
control other user's access to the database's objects.

By removing the Admin account from the Admins groups, the Admin becomes virtually useless.
After our database is secure, if any one successfully logs in as the Admin user, they find that
they don't have very many rights. If anyone needs to log in as a user with full rights, they should
use the new workgroup administrator that we created Click Next

Specify the location where you want the unsecured backup to be stored. You will want to
remove the .bak file extension and replace it with a .mdb extension. Click Finish.
Access will then create the workgroup information file(WID), a secured version of your database,
an unsecured version to the location you specified, and a One-Step Security wizard report.

• The One-Step security wizard report lists the name of the secured and unsecured
databases, the name and properties the WID, the name of all secured and unsecured
objects, group names and properties, and all user information.
• It is recommended that you print a hard copy of the report and place it in a secure
location because of the sensitivity of some of the information contained.
• Do not save the report.

The Security Wizard will then tell you that it encrypted the database and that you must exit
Access and open the database in the future by using the shortcut on the Windows desktop to
the database's WID.

Re-Log into Access the new workgroup administrator that you created previously.

You'll need to shut down and restart Access to be able to log in.

Set up a password for the new workgroup administrator.

Up to this point, the new workgroup administrator doesn't have a password. You can set up a
password for this account under Tools > Security > User and Group Accounts > Change Log
On Password.

Run the Security wizard under Tools > Security > User - Level Security.

This step creates a new database and copies all the current database's objects into it. The
Security Wizard does 4 things for us.

The Wizard sets the owner of the database from Admin to the new workgroup administrator.
This is done by creating a new database while logged in as the new workgroup administrator. If
we had left the database owner as the Admin user, then the admin user would still be able to
administer certain permissions of the database objects.

The Security Wizard changes the owner of each object in the database from Admin to the new
workgroup administrator. The owner of any object has special administrator privileges that we
don’t want any one to have except the new workgroup administrator. This step can be done
manually, but the Security Wizard automates this for us.

The Security Wizard removes all permissions from the Admin user. It also removes all
permissions from the Users group account, except for the Database Open/Run permission
which allows a user to open the database. Every user account that is created is automatically
added to the User group. Before we ran the Security Wizard the User group had all permissions
to all database objects.
Controlling MS Access Login Behavior

The Workgroup file (.MDW) should be located in the same folder as the BE. Your .MDW file
should be named differently than your BE. (Ex: BE name = AccountingBE.MDB, WorkGroup
name = AccountingWG.MDW) Your shortcut to open your database will look similar to:

"Full Path to MSAccess.EXE" "Full Path to local copy of the FE" /wrkgrp "Full Path to
Workgroup file"

http://www.techonthenet.com/access/security/use_mdw.php

Note: To apply a database password you must sign in to the database in Exclusive mode.

This can be accomplished by doing the following:

• Open Access. (MSAccess.EXE, NOT your database)

• Choose Open an existing file.
• Browse to your BE or FE. (Single-Click only)
• Click the dropdown menu on the Open button.
• Choose Open Exclusive. (Your database will open)
• Choose Tools >> Security >> Set Database Password…

When applying a password to the BE, this should be done before the links from the FE are
created. If the links are already in place, manually delete the linked tables from your
development FE. Then follow the steps outlined above in the Create the FE section to re-
establish the links in your FE to your new password protected BE. You will be prompted for the
password during the linking process once, but after that you should not receive any more
prompts. The password will be permanently stored in the link. Keep this in mind if you ever have
a need to change your database password. You will need to delete and recreate all the links in
the FE.

If you don’t want the user to enter a password you can incorporate this password in the shorcut

"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" /user paul /wrkgrp

"S:\\ashfp01\LackeyP$\QADR Workgroup.mdw" /pwd "letmein"

multiuser access db

http://www.access.qbuilt.com/html/multiuser_dbs.html