By splitting your Access database you separate the application into the front end and data (tables) into the back end. This is a good practice for all software including Access applications. This is why I recommend that every database should be split into an application/front end and data/back end. It is not just for multi-user applications/databases. I always split a database from the start. Even if it is just for a single user on a standalone computer.
Splitting a database is not just for multi-user databases.
It's about good software design!
Why you should split every database used by multiple users at the same time
An Access database should never be opened by more than one user at a time. What? Access is supposed to be able to create a multi-user database. I can be used for multi-user applications. The way you do this is to split the database into an app (front end) and data (backend). Each user will have a copy of the app (front end) that is not shared. The data (back end) is shared by having each user’s app (front end) link to the tables is the shared back end. Only the app (front end) is actually opened by Access directly.
Good Multi-User software is split into Application and Data
I don’t know of any good multi-user software that is not split into a front end and back end. All software that uses an RDBMS like an SQL Server, is split. The RDBMS is the data or back end. This Includes web sites A web site is a back end. The browser on each user’s PC/device/smartphone is the front end. The front end is the ASP/PHP/web scripts that generate the HTML to be sent to the end user's PC/device.
When to split your database?
While you might think it is a good idea to wait until you are ready to deploy your database to split it, I urge against this. I actually find that having a split database during the development and testing phases also aids in many ways.
Some reasons why I start every database split:
- Most importantly, it helps protects the data!
- Easily switch between back ends for better testing!
- Designing in the same environment that the application will be used allows better testing as you build the app.
- easy to test ideas on copies
- backups are easier
- you avoid the need for retesting everything later after the app is split
- Deploying updates to Forms, Reports, Queries, and Modules is as easy done by replacing the Application (Front end) file.
- If every user has their own copy of the front end then you avoid issues with different versions of Access being used at the same time.
- You can exceed the 2 GIG database file size limit by splitting your data into multiple back ends.
With a split database, your app (front end) can be 2 GIG and your data (back end) can be 2 GIG with a single back end. This allows you to safely exceed the Access 2 gig limit for a single database.If you have some very large tables you could split your data into multiple back ends. The downside is that you can't have the database engine enforce Referential Integrity between tables in separate databases. By splitting your data into multiple back ends, your data can safely exceed the 2 gig limit for a single Access database. When your data grows to this size you really should consider upsizing your data into an SQL Server.
I have been using the Access runtime since 1997 when I purchased the Access Developer edition. The Developer edition included a license to distribute the Access runtime. Starting with Access 2007 Microsoft has made the developer extensions and a license to distribute the runtime free.
Access VBA has not really changed that much in many years for desktop applications. I have code that I wrote in Access 2.0 in 1994 that works in Access 2016.
If something worked in 2000 or 2002/2003 then it will probably work in the newer versions. Access 2007/2010/2013/2016 will open an Access 2000/2002/2003 database without having to convert it to the newer accdb format.
There were a few new features introduced on Access 2007 that require the example to be in the new 2007 (.accdb) database format. For example, the attachment data type requires the accdb format with Access 2007 and later. Working with things like the Ribbon, Rich Text, and Save as PDF also require the newer accdb format with Access 2007 and later.
Access 2010 introduced some new User Interface features for command buttons. The database will still work in 2007 but you will not see the new command button features. The button will look like the 2007 command buttons.
TIP: It is generally safe to assume that if an Access version is specified in an
artilce or example that is applies that version and later.
There are several methods you can use to deploy the new Application (front End) version to all the users on the local network (LAN).
Here are some of the commonly used solutions:
1) Manually copy the file from the server to a local folder.
2) Use a .CMD/.BAT file to copy the new version from the server and launch the application (front End)
3) Use some type of auto-updater. This will automatically detect and copy a new version application (Front End).