Link the front-end database to the tables in the back-end database.Delete all the tables from the front-end database.Delete all the non-table objects from one of them and make that your back-end database.If the applicationĮvolves to need the features of SQL Server, you can still use the front-end database and link to data stored in SQL Server. This also sets the stage for migration to SQL Server or SQL Azure. To multiple back-end databases if necessary.
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 A single masterįront-end application database is copied to each user’s machine, but is not necessary to back up. Since the data is stored centrally and can be backed up and compacted, database administration is simplified. Simplify System Administration and Maintenance
The split database design minimizes this problem and avoids code corruption from impacting data corruption. Without splitting a database, multiple users running the same database on the network increase the chance of database corruption. On their desktop rather than running it off the network each time they use it. Performance can be significantly enhanced and network traffic reduced when the user has a copy of the front-end database installed Improve Performance and Minimize Database Corruption
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. Of course, if you modify table structures or add/delete/rename tables, you’ll need to apply those changes to the back-end database. Which automatically uses the current data. Releasing new versions and bug fixes becomes much easier since only the application part needs to be distributed Deploy Updates without Worrying about DataĪpplication enhancements are simplified since they are made in the front-end database without worrying about changes to the data in With temporary tables for each user in their front-end database, conflicts and collisions among multiple simultaneous users are avoided. They share the back-end database without locking it exclusively. Here are some of the major reasons to use a split database architecture: Multiuser SupportĮach user has the application and private tables in their copy of the front-end database. It also improves performance and reduces the incidents of database corruption. Assuming the application doesn’t change that often, the separationĪlso makes it easier to just backup the data database since only that is changing everyday.
Separating your application and data databases enables you to support multiple users and upgrade theĪpplication without wiping out data. Is designed to let you support multi-user databases and simplify how you enhance the application over time. One of the most important architectural designs is splitting the database into a front-end and back-end database. Life of its own and the overall design becomes critical. Very simple and trivial, but over time, it becomes more important as you add data, features, and even share it with others. Microsoft Access lets you easily create databases to store and present your data in forms and reports. Microsoft Access Split Database Architecture to Support Multiuser Environments, Improve Performance, and Simplify Maintainability Provided by Aparna Pophale, Quality Assurance Specialist updated by Luke Chung, President