MICROSOFT ACCESS SPLIT DATABASE ARCHITECTURE TO SUPPORT

MULTIUSER ENVIRONMENTS, IMPROVE PERFORMANCE, AND

SIMPLIFY MAINTAINABILITY
Microsoft Access lets you easily create databases to store and present your data in forms
and reports. When starting, a database may be very simple and trivial, but over time, it
may become more important as you add data, features, and even share it with others. It
gains a life of its own and the overall design becomes critical.
One of the most important architectural designs is splitting the database into a front-end
and back-end database. This is how Access is designed to let you support multiuser
databases and significantly simplify how you enhance the application over time.
Separating your application and data databases enables you to support multiple users
and upgrade the application without wiping out their data. Assuming the application
doesn’t change that often, the separation also makes it easier to just backup the data
database since only that is changing every day.

A Split Database Design: Front-End/Back-End Databases

Splitting a database is a relatively simple concept. You take an existing Access
MDB/ACCDB database with its tables, queries, forms, reports, macros, modules, etc. and
divide it into two databases:
 The “Back-End” database just contains the tables
 The “Front-End” database contains the application objects (everything except the
tables) and links to the tables in the back-end database
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:
Multiuser Support
Each user has the application and private tables in their copy of the front-end database.
They share the back-end database without locking it exclusively.
With temporary tables for each user in their front-end database, conflicts and collisions
among multiple simultaneous users are avoided.

Deploy Updates without Worrying about Data

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 which automatically uses the current data. Of course, if you modify table
structures or add/delete/rename tables, you’ll need to apply those changes to the back-
end database.
Without a split database architecture, when you create a new version, you’ll need to
update the database AND any data your users changed since your last copy.
Improve Performance and Minimize Database Corruption
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.
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.
Simplify System Administration and Maintenance
Since the data is stored centrally and can be backed up and compacted, database
administration is simplified. A single master front-end application database is copied to
each user’s machine, but is not necessary to back up.
Scalability
The split database architecture provides an opportunity to expand a database size
beyond the 2 GB limitation of Access since the front-end database can link to multiple
back-end databases if necessary.
This also sets the stage for migration to SQL Server (or SQL Azure). If the application
evolves to need the features of SQL Server, you can still use the front-end database and
link to data stored in SQL Server.

How to Split Your Microsoft Access Database

You can manually split your database by:
1. Copying it
2. Deleting all the non-table objects from one of them and make that your back-end
database
3. Delete all the tables from the other “front-end” database, then link to the tables in
the back-end database.
Or, you can use the Microsoft Access Database Splitter Wizard to split the Access
database. Consider this example:
Open a Tasks template form Microsoft Access. The Tasks database is designed with
tables, queries, forms and reports. The database contains three tables Contacts and
Tasks (2007 version also have Filters). To open a Database Splitter, select Database
Tools tab from Access ribbon and in the Move Data pane, click on Access Database
option.
Database Splitter wizard starts.

Click on Split Database button and it opens the Save dialog window. Provide name for
back-end copy.
So "Task_Back-EndCopy.accdb" name is provided here for Tasks database. This back-
end database copy can be saved on a network to share among multi users and front –
copy can be available to each user separately at their own desktop.
When the confirmation message box shows, click the OK button.

Now take a look at the tables in the Navigation pane, which show small arrows at the
left side of the table names. This indicates that these three tables are now linked to the
Tasks database, and resides in the Back-end database.
So this way the front-end copy will have all forms, reports and queries (no tables). Data
changes made in the front-end copy will also update the back-end copy, which stores
only tables. Now add a new record to the Contact List, save and close the database.

If you open back-end copy of the database and select Contacts table. This new record
appears in the table.
This way all users work on the same database using their own front-end copy, and data
changes reflect in the back-end database. Split database architecture gives a look of
Client-Server database technology by storing database tables at back-end server and all
programming part such as forms, function, queries at front-end client side.
Access databases can link to older versions of Access database formats. So even if the
front-end database is in an Access ACCDB format, the linked back-end database can be
an MDB in Access 2000 or 2002-2003 formats or an ACCDB.

Keeping Private Tables

If you want to have private tables in the front-end database, you’ll want to import them
into your front-end database and remove them from your back-end database. One of
the amazing and powerful features of Microsoft Access is its ability to use data from a
local or linked source in its queries, forms, reports, macros, and modules. If you need to
change the table’s location later, you can move it without impacting the objects that
depend on it.
One caveat is that if you have tables with field lookups to other tables, those tables
should be in the same database. Otherwise, if you open that source database and that
table, its lookups won’t appear which can cause data entry and data integrity issues.

Relinking Microsoft Access Tables

Tables can be relinked interactively with the Linked Table Manager or programmatically
via VBA.
Linked Table Manager
Once the database splitting procedure is finished, you can relink the linked tables using
Linked Table Manger.
 In Access 2010 and 2013, from the External Data ribbon, select Linked Table
Manager
 In Access 2007, it's on the Database Tools ribbon
 In Access 2003 and earlier, it's under Tools, Database Utilities

Select the table names which you want to update and click on Ok button. If you want to
link to a database located in another drive or folder, check the Always prompt for new
location box. This is common if you develop the front-end database on your local drive
with a local copy of your back-end database (to avoid testing on the live data), then
need to deploy it.
Always make sure that links are correct before you distribute them. It shows message
for successfully linking.
Relinking Tables Programmatically using VBA
You can also write some VBA module code to update a linked table (from our royalty-
free source code library Total Visual SourceBook):

Function ReLinkTable(strTable As String, strPath As String) As Boolean

' Comments: Re-links the named table to the named path
' Params : strTable Table name of the linked table
' strPath : full path name of the database containing the real table
' Returns : True if successful, False otherwise

Dim dbsTmp As DAO.Database

Dim tdfTmp As DAO.TableDef
Dim strPrefix As String
Dim strNewConnect As String

On Error GoTo PROC_ERR

Set dbsTmp = CurrentDb()

Set tdfTmp = dbsTmp.TableDefs(strTable)

strPrefix = Left$(tdfTmp.Connect, InStr(tdfTmp.Connect, "="))

strNewConnect = strPrefix & strPath

tdfTmp.Connect = strNewConnect
 tdfTmp.RefreshLink

ReLinkTable = True

PROC_EXIT:
dbsTmp.Close
Exit Function

PROC_ERR:
ReLinkTable = False
Resume PROC_EXIT
End Function

Updating VBA Code for Linked Tables

Adjusting Seek Statements
For the most part, separating the data into a data database does not affect your
application. The queries based on the linked tables remain the same, as do your forms,
reports, and code. The main exception is Seek statements. Seek statements are used in
code to find a record. They are very fast because they use an index you specify. For
example, for a given table (strTable), index (strIndex), and search values (varValue1
and varValue2):

Dim dbs As DAO.Database

Dim rst As DAO.Recordset
Dim fFound As Boolean

Set dbs = CurrentDb

Set rst = dbs.OpenRecordset(strTable)
rst.Index = strIndex
rst.Seek "=", varValue1, varValue2
fFound = Not rst.NoMatch

However, this code fails if the table is linked. This is very frustrating and many
developers resort to the FindFirst command instead. Unfortunately, FindFirst is very
inefficient. It does not use an index and performs a slow sequential search through the
entire table. This can be very painful for large tables. The good news is that you can use
Seek on linked tables. It’s a matter of properly identifying the database where the table
resides. Often, you will know the linked database name and you can easily set the
database variable (where strLinkedDB is the linked database name):

Set dbs = DBEngine.OpenDatabase(strLinkedDB)

The example below is a general solution where the code tests a table and changes the
database variable if it is linked:

Dim dbs As DAO.Database

Dim tdf As DAO.TableDef
Dim strConnect As String
Dim strLinkedDB As String
Dim rst As DAO.Recordset
Dim fFound As Boolean

Set dbs = CurrentDb

Set tdf = dbs.TableDefs(strTable)

' Connect = "" if it is not a linked table

strConnect = tdf.Connect
If strConnect <> "" Then
' Database name follows the "=" sign
strLinkedDB = Right$(strConnect, Len(strConnect) - InStr(strConnect, "="
))

' Change database handle to external database

dbs.Close
Set dbs = DBEngine.Workspaces(0).OpenDatabase(strLinkedDB)
End If

Set rst = dbs.OpenRecordset(strTable)

rst.Index = strIndex
rst.Seek "=", varValue1, varValue2
fFound = Not rst.NoMatch

Your front-end database is now properly linked and ready for deployment across your
network.
Managing Front-End Databases on Each Desktop
With a split database design, you'll need to distribute the front-end database to each
user. By residing on their local machine, the performance of your application will
improve. However, this adds an extra level of complexity when your application
changes.
Knowing an Update Exists
If you have a new version of your front-end database, you'll need to replace each user's
database with the new one. This means your front end database needs to know what
version it is and not run if it's not the current one, and provide a mechanism to get an
update.
This can be easily done by adding a version table in the front-end database and the
back-end database. You manually update the table in the front-end database with its
version number when you create a new build. The back-end database contains the latest
version number. When the front-end database starts, it compares the two tables and
proceeds if the version is okay and stops if not. You'll then need a process to replace it.
Automating the Version Detection and Update Process
FMS offers a commercial software product, Total Access Startup, to simplify the
deployment of your Access applications. It lets you centrally manage each Access
application by identifying the master front end database, the location where it should be
installed on each user's desktop, and its version.
Rather than running the Access database directly, a shortcut is provided to each user so
the Total Access Startup program verifies the right version of Access is being launched
with the right version of your front-end database. If the current local database doesn't
exist or is out of sync, the latest version is installed on the user's desktop along with any
setup routines that are required. The process is seamless and you can easily change the
deployments centrally. Only one copy is needed to manage all the Access applications
across your network.

Additional Resources
Multi-user Microsoft Access applications are pretty important to your organization. FMS
offers additional resources designed for this environment:
 Total Access Analyzer to help you create and diagnose your databases to find
errors, suggest enhancements, and improve performance.
 Total Visual Agent to ensure your database maintenance tasks like database
backups and compacts are scheduled and executed. Can also launch processes on
a recurring basis.
 Total Access Admin to monitor in real-time who’s entering and exiting in your
Access database.
Performance Tip
 Significantly Improve the Performance of Microsoft Access Databases with Linked
Tables
Microsoft Resource
  How to manually split a Microsoft Access database

Conclusion
Microsoft Access is a very powerful platform that lets you easily create solutions that can
significantly improve the productivity of your team. With a properly split database
architecture, you’ll find it even easier to create, enhance, and share your application.
Good luck!

HOW TO MANUALLY SPLIT A ACCESS DATABASE IN

MICROSOFT ACCESS
Advanced: Requires expert coding, interoperability, and multiuser skills.
This article applies to a Microsoft Access database (.mdb) file or to a Microsoft Access database (.accdb) file.

Summary
For various reasons, you may decide to split the database into either a front-end application or
a back-end application. The back-end database contains the tables and is stored on a file server.
The front-end database that links to the back-end tables contains all the forms, the queries, the
reports, the macros, and the modules. The front-end database is distributed to the workstations
of the users.

This article describes how to split the database manually instead of by using the Database Splitter
utility.

More Information
To split the database in Microsoft Office Access 2003 and in earlier versions of Access,
follow these steps:

1. Create a new blank Access database.

2. On the File menu, point to Get External Data, and then click Import.
3. Locate and select the database that you want to split.
4. On the Tables tab, click Select All, and then click OK.

Notice that Access imports all of the tables into the new database, which is your back-end
database.

5. Store the new back-end database on a network share and make sure that all the users have full
permissions to the share.
6. Create a second new blank Access database.
7. On the File menu, point to Get External Data, and then click Link Tables.
8. Select the back-end database that you just created.
9. On the Tables tab, click Select All and then click OK.

Notice that Access links the tables in the back-end database to the front-end database.

10. On the File menu, point to Get External Data, and then click Import.
11. Select the original database that you are splitting, and then click Import.
12. On the Forms tab, click Select All. Repeat this step on all tabs except the Tables tab. Because
you have already linked to the tables, you now only need to import the rest of the objects.
13. After you have selected all of the objects except for tables, click OK.

Notice that you now have all the tables linked and have imported the remaining objects.

To split the database in Microsoft Office Access 2007, follow these steps:

1. Create a new blank Access database.

2. On the External Data tab, click Access in the Import group.

3. In the Get External Data dialog box, click Browse to locate and select the database that you
want to split, click to select the Import tables, queries, forms, reports, macros, and
modules into the current database. check box, and then click OK.

4. In the Import Objects dialog box, click Select All on the Tables tab, and then click OK.

Notice that Access imports all of the tables into the new database, which is your back-end
database.

5. Store the new back-end database on a network share, and make sure that all the users have
full permissions to the share.

6. Create a second new blank Access database.

7. On the External Data, click Access in the Import group.

8. In the Get External Data dialog box, click Browse to select the back-end database that you
created, click to select the Link to the data source by creating a linked table. check box,
and then click OK.

9. In the Import Objects dialog box, click Select All on the Tables tab, and then click OK.

Notice that Access links the tables in the back-end database to the front-end database.

10. On the External Data, click Access in the Import group.

11. In the Get External Data dialog box, click Browse to select the original database that you
are splitting, click to select the Import tables, queries, forms, reports, macros, and modules
into the current database. check box, and then click OK.

12. In the Import Objects dialog box, click Select All on the Forms tab, repeat this step on all
other tabs except the Tables tab because you have already linked to the tables. You now only
need to import the rest of the objects, and then click OK.

Notice that you now have all the tables linked and have imported the remaining objects.

Notes

This database is the front-end database. You can distribute this front-end database to the
workstations so that each user has his own copy of the front-end database.

You have now successfully split your database, which will improve performance. Now when
a user opens a form, the form opens locally on their computer, and is not sent across the
network. The only data that comes across the network is the data in the linked tables.

Reasons Why You May Want to Split Your Database

The following are typical reasons to split a database:

 You are sharing your database with multiple users on a network.

 You have several people developing in the database and you do not have Microsoft Visual
Source Safe installed.

 You do not want your users to be able to make design changes to tables.

The most common reason to split a database is that you are sharing the database with multiple
users on a network. If you simply store the database on a network share, when your users open
a form, query, macro, module, or report, these objects have to be sent across the network to
each individual who uses the database. If you split the database, each user has their own copy
of the forms, queries, macros, modules, and reports. Therefore, the only data that must be sent
across the network is the data in the tables.

Note To split the database, you can also use the Database Splitter utility.
 SIGNIFICANTLY IMPROVE THE PERFORMANCE OF
MICROSOFT ACCESS DATABASES WITH LINKED
TABLES
A Split Microsoft Access Database Architecture Offers Many
Advantages
A split database architecture is best for developing, maintaining, and deploying Microsoft
Access applications. The front-end database contains all the Access objects except the
tables which reside in a separate back-end Access Jet database. The front-end database
links to the tables in the back-end database, so it can be updated without worrying
about changes to the data.

This is particularly important for multi-user applications where

each user has a copy of the front-end database on their machine sharing the same
centralized data. When the application is enhanced (new queries, forms, reports, code,
etc.), it is simply distributed to each user. Programs like our Total Access Startup can
centralize and automate the distribution process.
If you are not familiar with a split database architecture, read our paper on Splitting
Microsoft Access Databases to Improve Performance and Simplify Maintainability

Microsoft Access Database with Linked Tables Sometimes Perform

Poorly
When a single database is converted to a split-database design, one sometimes sees
significant performance degradation, especially over a network. Speed may vary with
different portions of the application and number of users. Some people settle for this but
there may be a simple way to significantly improve performance.
Microsoft Access Lock Files
When a database is opened, Microsoft Access creates a lock file on disk. You may see
these are *.LDB or *.LACCDB files. When the database is closed, the lock file is deleted.
This is not a big deal for a single MS Access database application which would create the
lock file when the database is opened and maintain it until the database is closed. But in
a linked database design, the lock file on the back-end database may be created and
deleted every time a table is opened and closed. When no connections to any tables on
the back end database remain open, the lock file is deleted. That takes time.

Always Keep a Connection Open to the Back End Database While

Your Application Runs
You can significantly improve the performance of your Access database by maintaining
an open connection to the back-end database throughout the time your front-end
database is opened.
By forcing Access to keep the linked table's database open, Access avoids creating a new
lock on the backend database every time one of its tables is used. This lets you open
tables, forms, and reports much faster. Over a network, you'll usually see a substantial
improvement with how quickly a form opens when it's based on a linked table.

The DAO OpenDatabase Method

To create a persistent connection to the linked database, open a MS Access database
variable in VBA using the DAO OpenDatabase method. Keep this variable open as long
as your application is running.
Procedure Code
The procedure below supports multiple backend databases. Edit the section with the list
of databases to match your backend database(s):

Sub OpenAllDatabases(pfInit As Boolean)

' Open a handle to all databases and keep it open during the entire time
the application runs.
' Params : pfInit TRUE to initialize (call when application starts)
' FALSE to close (call when application ends)
' Source : Total Visual SourceBook

Dim x As Integer
Dim strName As String
Dim strMsg As String

' Maximum number of back end databases to link

Const cintMaxDatabases As Integer = 2

' List of databases kept in a static array so we can close them later
Static dbsOpen() As DAO.Database
If pfInit Then
ReDim dbsOpen(1 To cintMaxDatabases)
For x = 1 To cintMaxDatabases
' Specify your back end databases
Select Case x
Case 1:
strName = "H:\folder\Backend1.mdb"
Case 2:
strName = "H:\folder\Backend2.mdb"
End Select
strMsg = ""

On Error Resume Next

Set dbsOpen(x) = OpenDatabase(strName)
If Err.Number > 0 Then
strMsg = "Trouble opening database: " & strName & vbCrLf & _
"Make sure the drive is available." & vbCrLf & _
"Error: " & Err.Description & " (" & Err.Number & ")"
End If

On Error GoTo 0
If strMsg <> "" Then
MsgBox strMsg
Exit For
End If
Next x
Else
On Error Resume Next
For x = 1 To cintMaxDatabases
dbsOpen(x).Close
Next x
End If
End Sub

Invoking the Procedure

Call this when your application starts:

OpenAllDatabases True

When you finish, call this to close the database variables/handles:

OpenAllDatabases False

For instance, if you have a form that controls the application and remains open during
the entire time the user is using your database, add the code to the OnOpen and
OnClose events.
This simple technique yields considerable performance gains.

Additional Resources
 Microsoft Access Best Practices: Finding Errors, Suggestions, and Performance Tips
in Your Databases with Total Access Analyzer
 Source code for Starting Microsoft Access databases in Total Visual SourceBook
 Module class for Managing Microsoft Access Linked Tables and Databases in Total
Visual SourceBook
 Splitting Microsoft Access Databases to Improve Performance and Simplify
Maintainability
 100+ Microsoft Access Performance Tips to Speed up Your Access Databases
 More tips
Good luck!