|
Free Lessons Courses Seminars |
TechHelp Fast Tips Templates |
Topic Index Forum ABCD |
|
||||||
|
|
Split Your Database By Richard Rost 
6 years ago
How and Why to Split Your Microsoft Access Database In this video, we'll talk about what splitting your database means, the benefits and drawbacks, and I'll show you how to do it. Junior from Baton Rouge LA (a Gold Member) asks: I've heard a lot about the benefits of splitting my Access database. Can you tell me what this is all about? MembersI'll show you how to move or rename your backend file, use the linked table manager, create multiple back end files, and manually create links to tables. Silver Members and up get access to view Extended Cut videos, when available. Gold Members can download the files from class plus get access to the Code Vault. If you're not a member, Join Today! File SharingIf you need help setting up a shared folder on your network, watch this:
Links
Other Articleshttps://www.techrepublic.com/blog/10-things/10-plus-reasons-to-split-an-access-database
IntroIn this video, we will talk about how and why you should split your Microsoft Access database into front end and back end files. We'll discuss the benefits of splitting, such as improved performance, easier updates, better security, and reduced corruption, as well as some drawbacks to be aware of. I will show you how to back up your database, set up a shared folder, use the built-in Access tool to split the files, compact and encrypt the front end for users, and offer tips for distributing the updated front end. You'll also get practical performance suggestions for working with split databases.TranscriptWelcome to another TechHelp video brought to you by AccessLearningZone.com. I am your instructor, Richard Rost. In today's video, we are going to talk about splitting your database. How and why should you split your database in Microsoft Access?Today's question comes from Junior, one of my Gold members in Baton Rouge, Louisiana. Junior asks, I've heard a lot about the benefits of splitting my Access database. I just have a small office with three users. The database seems to run just fine from a shared folder on my PC. Should I bother splitting it? Well Junior, usually I say if it ain't broke, don't fix it. But in this case, you may benefit from splitting your database in ways you didn't realize before. For example, if any of your three users have ever complained that the database was running slow, splitting it might speed that up. Or if you've ever tried to make design changes on one of your forms or reports and you had to kick everybody out of the database, splitting the database prevents that as well. So what exactly is splitting your database? Splitting your database is dividing it into two or more files. One file, called the front end, contains your forms, reports, queries, macros, and modules. The other, called the back end, contains just your tables. Splitting your database can make it more efficient. It will run faster. It's easier to maintain and update. It's more secure. It reduces corruption. And it's easier to scale it up later. If you've got your Access database shared on your network with a couple of other users, this is probably how you are running it - an unsplit database. You have one ACCDB file, the Access file. It is on a network share that could be on your PC in a shared folder or up on a server. All of the users are running that file directly. Splitting the database creates two files. One has the forms, reports, queries, macros, and modules in it, and the other one has the tables in it. Now you can do this and run both files on the server, but again, all of your users are sharing the same front end file, which is not the most efficient way to do it. The better way to run it is to split the database and give each user a separate copy of the front end file. That way all of their forms, reports, queries, macros, and modules are loaded on their computer. So that information does not have to go over the network wire, just the data from the tables is transmitted. You can also encrypt that front end file so they cannot get into your form design, your report design, your VBA code, and so on. You could also split your back end into multiple database files as well. Certain users might have access to different information. For example, all of your sales reps do not need to see all of your accounting information. So your accounting people, the managers, and such could have a different back end database file that only they have access to. You can control who accesses what through your Windows permissions. Later on, if you decide that you've outgrown Access for your data storage needs, you could easily upgrade to SQL Server or a cloud-based server if you want to deal with remote access. Now, what are the benefits of splitting? Splitting your database makes it faster and more efficient. Only data is transferred over your network. All the forms, reports, all that stuff is stored locally on each user's computer, so that material is not transmitted over the wire. Each user has their own local copy of the front end file. This makes the database operate faster and the data is more readily available. Also, if you want to run reports on a large volume of information, you can make queries to copy that information down to your local database. So it makes one copy operation, brings all that data down into a temporary table, then you can do all your reporting and running your reports on that local data, so that's not all running over the network wire. I had one client who had her month-end reporting that she had to do, and it took forever because every single report, every single query, was running off the table on the server. I wrote one query to copy all that information down into a temporary table in her local database, and then her reports ran really fast. Split databases are easier to update and maintain. Changes to the front end can be made without interrupting your users. If you are all sharing the same database file and you want to change one thing on a report, you have to kick everybody out of the database. The only time you would normally have to do that now is if you are making a change to one of the tables in the backend. If you are just changing forms, queries, or reports, which is 90% of the time what you're changing, you can modify your front end copy and then just distribute a new front end to your users. You do not have to worry about importing data. If you are running off of a single database file and you make changes, you have to re-import all your data from the tables. Splitting the database avoids that. You could even have multiple developers on your network working on their individual front ends. You would have to merge the changes, but if you are working on some management forms and you have someone in the accounting department working on certain reports, as long as you get together and say, hey, do not change these things, I will work on these things, then you can later put them together without taking the whole database down. Splitting your database is more secure. You can have separate back end files for secure data. Like I said before, you can have a different network share where your accounting information is stored or credit card numbers or things like that. All your normal users are still using the same database, but they cannot get to those tables. Sensitive information can also be stored locally if you want to. You do not have to put all of your tables up on the server. You could have each individual user with some of their information, like settings, for example, stored locally. And as I mentioned before, with encryption, users cannot modify the database design. They cannot change forms, they cannot change queries, and they cannot modify reports. It is all locked down. Some other benefits: Microsoft Access has a two gigabyte file size limitation. That means the largest any one given ACCDB file can be is two gigabytes, even with the 64-bit edition. However, by splitting your database, you can have multiple files up to two gigabytes in size. So now really your limitation is one table can only be a maximum of two gigabytes, and even then you can string those together. Knowing how to split your databases will allow you to have much, much larger sets of data. Splitting the database reduces corruption. Usually, if your database goes corrupt, it is a problem with the front end file. That normally happens if there is a network error, for example, and the user loses connection to the server. Nine times out of ten in my experience, the corruption is in the front end, and even if you cannot repair it, you just replace the front end file and copy it from one of the other stations. Generally, the data on the server is fine. Finally, with a split database, it is easier to upscale later to either SQL Server or a different server platform or a cloud-based database. You can very easily take those tables and just upload them to a different server platform and then relink your tables. There are a lot of benefits to splitting your database, and there are really only two drawbacks that I can think of that are worth mentioning. First, distributing your front end updates can be challenging. Whenever you make a design change, you have to share it with all the different users on your network. Unless you have made changes to features they do not need, like if you have changed some managerial form that all the users do not need, that is fine, then do not bother. But if you want to distribute a new update, you can either email it to people or you can put it in a shared drive somewhere, tell them and have them download it, but it is a manual process. I do have a database template called the Access Updater which I will talk about later, which does automate this process for you. And the other drawback is that you lose referential integrity in linked tables. For example, if you set up a relationship in your database between customers and orders and you have referential integrity on with Cascade Deletes, that says if I delete a customer, delete all their orders. I usually do not recommend using Cascade Updates and Deletes, but if you do have your database built that way, you will lose that ability if you have tables in different linked files. That almost never happens, but just keep that in mind. So as you can see here, the benefits of splitting your database far outnumber the drawbacks. Alright, so how do you split your database? Let's walk through it. Step one, back up your database. Hold on, let me put that in bold: back up your database. You should have a good nightly backup running anyway, so make sure it is backed up. One more time for the people in the back row: back up your database. Before you do anything crazy, like splitting it or running delete queries or update queries or any major changes, back up your database. You have been warned. Next step is to create a shared database folder somewhere on your network. This could be something like a UNC pathname like server\\sharename, or map a drive letter. I personally am preferential to drive letters. I have mine as Z:\\database on my network. If you have mapped network drives, Windows does a better job of connecting to those drives when Windows starts, versus if you just use the UNC paths, sometimes they do not connect right. If you do not know how to set up a shared folder on your network, that is a different video. Talk to your network administrator or look for my networking video. Make sure it is the same for everybody. It has to be the same share name or the same mapped drive letter for every user on your network that is going to be using this database. Next step is to split the database. It is very easy to do. It is a couple clicks in Access. I am going to show you how to do it in just a second. Then we are going to compact both databases. You have two database files now. You want to give them a good compact. Then we are going to encrypt the front end - that is making an ACCDE or an encrypted file. That is what we are going to distribute to our end users. How you distribute it to them is up to you. You can email it to them if it is small enough. You can put it on your shared drive and tell them to download it, or you can use my Access Updater software, which I will talk about in a few minutes. Let's see how this works in action. Here is my basic customer database. I use this template for a lot of my videos. Let's open this up and take a peek at it. It is a very simple database with the main menu, customers, orders, contacts, and so on. If you have watched any of my other videos you have seen this before. It has three tables in it: contactT, customerT, and orderT. Right now, all of these objects are stored in this database file. What I want to do is split this into two different files and put one of them up on my server and then give a different front end file to each of my users. I have already backed up my database. I have my shared database folder set up. There it is - it is on my server. I have it on the Z drive. I have Z and then \\database as a folder. So Z:\\database is where my database is located. Now we are going to split the database. It is under Database Tools, Move Data, and then pick Access Database. Database Tools, Move Data, Access Database is right there. It says this wizard moves tables from your current database to a new back end database. In multi-user environments, this reduces network traffic and allows continuous front end development without affecting data or interrupting users - basically what I just said. If your database has a password, you will have to recreate the password when the new database is created. Make a backup copy of your database before splitting it - another warning. Would you like to split the database now? Sure. Split database. Access will prompt you for a location for your database. I am going to put mine on my server database folder where I have it set up for all my users. Notice the file name is customerDBS and I have my database_BE for back end. That is fine. You can change it if you want to. Then I am going to hit Split. Now, my database is pretty small, but if yours is big and you have lots of tables, it may take a few minutes. Mine says database successfully split. Hit OK. Now take a look. Over here, your tables, the little icons have changed. There are little arrows next to them now that indicate they are linked tables. If you hold your mouse over it, it says Z:\\database\\customerDB_BE - that tells you where that table is located because you could have tables in here that are in different back end files. I am going to cover that in a different video. If I go to my database folder, you can see there it is right there. There is the ACCDB file that contains just our tables. If you open this guy up, you can see it contains just the tables. This database over here has links. That means it has no actual data in it. It is just links to those tables. The actual data is stored here. This is the only file you have to back up on a nightly basis unless, of course, you make design changes. You do not have to worry about backing up each user's front end. Have one copy backed up, of course. But any changes that they make to their data get saved on the server in these tables. The next step is to compact both databases just to make sure they are nice and small. That is real easy to do. It is under Database Tools, Compact and Repair. Just hit that. I have several whole videos on compacting and repairing and the benefits thereof. I will put a link in the description below the video. Next, we are going to encrypt and make an ACCDE file for the front end. So, we are going to go up to File, Save As, Make ACCDE. The file will be compiled into an executable-only file. Then hit Save As. Now, I usually drop this in my server folder. I am going to drop this in my Z:\\database folder. It is going to be customerdb.accde, and then hit Save. Now, I am going to close Access down. So what have I got now? I have actually got three different files. I have got the original database file, the ACCDB file that has just my forms, reports, queries, and so on in it. Keep that. Do not lose that. If you want to make design changes, this is the guy you are going to have to use. This file here is the one we just created, the encrypted file that we are going to give to our end users. This guy here is the back end that has the tables in it. Make sure you do not rename this now, by the way, because these other databases are pointing to this exact file. Once you have split it, you have to leave that file name right there. Now your users can open this file right here across the network, but you lose a lot of the benefits of splitting the database. What you want to do now is tell the users to copy this file to their desktops, copy that file to their individual desktops, and then open it up from there. If you have to run around once and do it all for them, that is what you have to do. Set them up with a shortcut, because now this front end database file will point to this back end file on the server. I just put it here so it is easy for everyone to get access to it. If I open this guy up now, this one is encrypted. I cannot go into design view. I cannot change anything in these forms here. Yes, users can still come in and modify your tables. There are a lot of things you can do to fully secure the database. That is a whole separate video. I have a whole seminar on locking down your database so users cannot just go willy-nilly and play with the data in the tables. I will put links in the description below this video for how to lock down your database more. But that is basically it. You have got your original database. It is now split. There is your back end with your tables. Now this ACCDE is the encrypted version that you are going to distribute to your users. When you make design changes, you have to make them in the original file up here, open this guy up. This is your admin copy. Do not lose it. This is the only one you can still go into design view with. You cannot reverse engineer these by the way. You cannot go from an ACCDE back to an ACCDB file, so make sure you do not lose this file. But when you make design changes, all you have to do again is go File, Save As, save this as another encrypted file, then tell all your users to download the new database. As I mentioned before, I have a database available that does this update for you. You basically install it on each user's machine, set up your database a certain way, and then with one click, you can update everyone's databases on your network by copying a new front end to their systems. There is more information on my website. I will put a link in the description below the video. So you have got your database up on your network, and it is running, and it is split, and everything is great. What are some tips I can give you for improving performance? The first thing I can say, and this really comes into play when you have got a really big set of data, a big table with lots and lots of records in it: try not to open objects that use all of the records. Do not open your customer form and show all customers, because if you have got 200,000 customers in there, and the user goes to the last record, that can take a while. A lot of data has to come across the wire. Try to use search forms. I have a video on my website and on YouTube on how to make a search form. Even something simple like this can really improve performance: a simple search form, where you can search for a first name or last name or phone number, and it will bring back just a couple of records that match your search, then open up the customer form based on the search results. That way, you are not chugging through 200,000 records to open up your customer form. I will put a link to this video down in the description. Try to create data entry forms for adding new records. A data entry form is simply a property in the form that says Data Entry. That way when you open up the form, it does not show all the records. It just goes to a blank new record, and you can type in new records that way. Now I know sometimes you need them, and I use DLookup all the time, but try to avoid aggregate functions and aggregate queries because the database has to chew through a lot of records. If you do not need to DLookup some stuff, try not to in a split database. There are sometimes faster ways, like using recordsets to get information instead of using DLookup. DLookup is a great function; I have several different videos on how to use it, but it is resource intensive and will chug through tons and tons of records to get the data that you want, especially DSum and DCount. Finally, try to use Top X queries to limit the number of records returned. If you are pulling up a list of customers and you really only care about the most recent 100 orders, pull up the most recent 100 orders and get that list of customers. Do not bring up your entire customer list just to sort through and get some orders. If you make one query at a time that limits your data, you will make things faster and speedier than making multiple queries. So if you want customers by order, make one query first that generates a list of the top 10 customers, then bring that back and make another query on that that maybe sorts them by name or whatever you want to do. Want to learn more about splitting your database and the benefits thereof? Check out the members-only extended cut edition of this TechHelp video. I will show you how to move or rename your database files using the Linked Table Manager. Then I will show you how to set up multiple back end files. Remember, we talked about it earlier: if you want to have your sensitive information for managers in a separate back end in a different network share, I will show you how to set that up. I will teach you how to manually link tables so you can specify pretty much anything you want as a back end database source. How do you become a member? Click on the Join button below the video. Silver members and up will get access to all of my extended cut TechHelp videos, live video and chat sessions, and other perks. After you click the Join button, you will see a list of all the different perks that are available - Silver, Gold, Platinum, and Diamond. But do not worry, these TechHelp videos are going to keep coming. As long as you keep watching them, I will keep making them, and they will always be free. If you enjoyed this video, please give me a like and share. Click on the Subscribe button to subscribe to my channel and be notified of any new releases. Check for additional resources down below the video. Click the Show More button and you will see a list of other links to other videos, downloads, resources, lessons, and lots more. If you have not yet tried my free Access Level One course, it is three hours long. You can find it on my website or on my YouTube channel. If you like Level One, Level Two is just one dollar and that is free for my members. Want to have your question answered in a video just like this one? Visit my TechHelp page and you can post your question there. Also be sure to stop by my Access forum on my website and also look for me on Facebook, Twitter, and of course, YouTube. Once again, my name is Richard Rost with AccessLearningZone.com. Thanks for learning with me and I will see you next time. QuizQ1. What does splitting an Access database mean?A. Dividing the database into front end and back end files B. Creating multiple backups of the database C. Upgrading the database to SQL Server D. Compressing the database to save space Q2. What does the front end file contain after splitting a database? A. Only tables and data B. Forms, reports, queries, macros, and modules C. Only user passwords D. SQL Server connection strings Q3. Why is giving each user a separate copy of the front end file more efficient? A. Because users do not need to back up their work B. Because all form, query, and report data stays local and only table data travels over the network C. Because table data is replicated to each user's machine D. Because Access does not permit shared files on networks Q4. What is a major benefit of splitting your Access database? A. It allows multiple databases to run on a single PC only B. It makes the database faster, easier to maintain, reduces corruption, and increases security C. It prevents the addition of new tables D. It disables all queries for remote users Q5. What happens if a user's front end file becomes corrupt in a split database? A. All data is lost permanently B. The user must rebuild the whole database from scratch C. The front end file can be replaced without affecting data on the server D. The back end file becomes corrupt as well Q6. Which of the following is NOT a drawback of splitting a database? A. Distributing front end updates to all users can be challenging B. You lose referential integrity in linked tables if split between back ends C. It is difficult to scale up to SQL Server later D. Updating design changes must be coordinated among users Q7. Why should you avoid opening forms that show all records in a large split database? A. It uses up all the drive space B. It causes Access to crash C. It forces the database to process and transfer many records over the network, slowing performance D. It prevents record editing Q8. How can you improve performance in a split database? A. Use search forms to limit and find specific records B. Always use aggregate queries C. Load all records at startup D. Only use macros for programming Q9. After splitting your database, what files do you end up with? A. Only one file with all data and forms B. An ACCDB with the front end, a back end ACCDB (tables), and an ACCDE file for user distribution C. Only an ACCDE file and a text file D. A single encrypted file only Q10. What must you always do before splitting your database or performing major changes? A. Disconnect all users from the network B. Back up your database C. Delete all unnecessary forms D. Create a new database from scratch Q11. What is an ACCDE file in the context of Access? A. An encrypted, compiled version of the front end database B. The back end file containing just tables C. An outdated file format D. A backup script Q12. Why is it important not to rename the back end file after splitting the database? A. The front end file cannot find the tables if the name or location changes B. Access will automatically relink the tables C. Back end files must be renamed for security D. Users need to access the renamed file directly Q13. What Access feature helps you manage and relink split databases if you move or rename them? A. Linked Table Manager B. Report Wizard C. Form View D. Property Sheet Q14. What is one advantage of splitting regarding database size limitation? A. It eliminates the two gigabyte limit entirely B. Each file can be up to two gigabytes, so you can have more data overall using multiple files C. The maximum size of all files together is one gigabyte D. The limits remain the same as with an unsplit database Q15. What happens if you try to reverse engineer an ACCDE file to an ACCDB file? A. It is easily converted back B. It is impossible; you cannot recover the original file C. It compresses the file further D. It exports all data to Excel automatically Q16. What should users do with the ACCDE file after a database is split? A. Open it directly from the server only B. Copy it to their desktop or local machine and open it from there C. Store it in the back end folder D. Leave it unused Q17. How can you automate the process of distributing front end updates to users? A. By manually emailing files each time B. By using specialized software like the Access Updater C. By disabling all user updates D. By deleting old versions Q18. Which property should be set on data entry forms for better performance with large data sets? A. Read Only B. Hide Data C. Data Entry D. Design View Q19. What is the main cause of corruption in an Access database in a multi-user environment? A. The network cable is unplugged B. The front end file becomes corrupt if the network connection is lost C. The back end file always corrupts first D. User passwords expire Q20. If design changes need to be made after splitting, where should they be done? A. On each user's local ACCDE file B. On the original front end ACCDB file C. On the back end file D. On the server hardware settings Answers: 1-A; 2-B; 3-B; 4-B; 5-C; 6-C; 7-C; 8-A; 9-B; 10-B; 11-A; 12-A; 13-A; 14-B; 15-B; 16-B; 17-B; 18-C; 19-B; 20-B DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks. SummaryToday's video from Access Learning Zone covers an important topic: splitting your Microsoft Access database. I will walk you through why and how to split your database, as well as the benefits and a couple of potential drawbacks you should be aware of.The discussion begins with a question about whether or not a small office with just a few users should bother splitting their database if it already seems to be working fine. While the old adage "if it ain't broke, don't fix it" might sometimes apply, splitting your database can provide advantages you may not have considered. For instance, if users sometimes notice performance issues or if making design changes requires everyone to log out, splitting the database can solve both problems. To clarify, splitting a database means dividing it into two (or more) separate files. You end up with a front end file that holds forms, reports, queries, macros, and code modules, and a back end file that contains only your tables. This structure brings a host of benefits: improved speed and efficiency, simpler updates, better security, less risk of corruption, and easier scalability for future growth. Most small offices, by default, run a single unsplit ACCDB file on a shared network folder, which means all users are working off the same file at the same time. Splitting the database lets you distribute a unique front end file to each user's desktop while keeping the tables centrally located on the server. This separation means each user's forms and reports stay local, with only the table data moving back and forth over the network. That makes things faster and eases network traffic. You can also encrypt your front end file, preventing users from tampering with your forms, reports, or VBA code. Flexibility increases as well. You can split your back end into multiple files if, for example, HR, finance, and sales each need to access different data. Windows permissions can be set up to ensure that users only see the data they are authorized to view. Down the road, if you outgrow Access for your data storage needs, you can transition to SQL Server or another cloud-based solution more easily with a split database. Let's review the specific advantages in more detail. Not only does splitting increase speed by keeping the more data-heavy forms and reports on each desktop, but it also streamlines reporting. For large operations, you can make queries to pull chunks of data into local temp tables, then run heavy reports locally instead of dragging all the data across the network every time. Updating and maintenance are also much easier. If you want to modify a form or report, you can make changes to your front end and distribute a new file to your users — no need to disrupt everyone actively working. If multiple developers are working in your environment, each can work independently on different front end copies. Only changes to the back end tables themselves (like creating new tables or fields) would require a coordinated update. On the security front, splitting means sensitive data can be secured by simply restricting access to certain back end files. You can also store some user-specific settings locally in each front end database rather than on the server. Encrypting the front end prevents users from altering your design, further locking down your solution. Another technical benefit is related to Access's two gigabyte file size limit. Since only the back end grows as you add more data, you can spread data across several files if needed, effectively working with much larger datasets than would fit in one file. Database corruption is less of a worry. Most corruption affects the front end — which can be replaced by giving the user a fresh copy — while your central data remains unaffected. If you lose or corrupt a user's front end, just provide a new one; the server data should be safe. Scaling your database solution upward is more straightforward, too. Migrating to SQL Server or some other back end is much easier when your data is already separated. There are really only two main downsides to consider. First, every time you release a new update to your front end (such as new forms or features), you need to distribute it to all users. This can be a manual process — collecting all the updated front ends and replacing them on each machine. You can email the update, use a shared drive for distribution, or automate it with a tool like my Access Updater database. The second issue is a technical one: you lose Access's built-in referential integrity for tables placed in different back end files. Most people do not rely on cascading deletes and updates across multiple files, but it is something to remember if you do. So how do you actually split your database? The first and most important step is to back up your database. I cannot stress this enough: always create a backup before performing major changes like splitting, running delete or update queries, or making other significant updates. Next, create a shared folder on your network accessible by all users, either with a UNC path or (preferably) a mapped drive letter to ensure reliable access. Set up your network so every user refers to this location exactly the same way. After your network location is set and your backup is ready, you can use Access's built-in database splitter. This is a straightforward process accessed from the Database Tools menu. Access will prompt you to save the back end (table) database to your network folder. After splitting, you will see your tables now display as linked objects in the front end, while the new back end file contains only the tables themselves. At this point, perform a compact and repair on both the front end and back end files to optimize performance. Then, compile your front end into an ACCDE format, which is a locked-down, executable version of your database that users cannot modify. This is the version you will distribute to each user. You should keep three files: your original ACCDB with all design elements (never lose this — it's the only version you can edit in design view), your locked-down ACCDE front end for users, and the back end file with the data tables. Advise users to copy the ACCDE front end to their local desktops and open the program from there, ensuring maximum efficiency. If you make updates to the front end in the future, make changes in your master ACCDB, generate a new ACCDE front end, then distribute the updated file to users. Tools like my Access Updater database can help automate this process and keep every user up-to-date. To further improve performance, avoid designing forms that open and display all records at once, especially in large tables. Instead, use search forms so users retrieve only the records they need. Data entry forms should be set with the Data Entry property so they open to a blank new record rather than all existing data. Aggregate functions like DLookup, DSum, and DCount can be resource-intensive in split databases, so try to use alternatives like recordsets where possible, or run summary queries that retrieve only what you need. Use Top X queries to limit the number of returned records when appropriate. If you are interested in seeing the full, step-by-step process, visit my website to watch the complete video tutorial. In the members-only extended cut of this TechHelp video, I walk through more advanced tasks, such as how to move or rename your database files using the Linked Table Manager and set up multiple back end files for handling sensitive information. If you wish to access extended content, live video and chat sessions, and more, consider joining as a Silver member or higher. You will find all the information about membership perks on my website. I also encourage you to check out my free Access Level One course if you are just starting out. If you want your own questions answered, you can submit them through my TechHelp page or participate in discussions on my Access forum and other social channels. You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends. Topic ListReasons to split an Access databaseDifferences between front end and back end files Advantages of splitting a database for performance Network considerations for shared databases Steps to prepare before splitting a database Creating a network shared folder for databases How to split a database using Access Database Tools Identifying linked tables after splitting Managing and storing front end and back end files Compacting and repairing both database files Encrypting the front end and creating an ACCDE file Distributing the front end to users Making design changes in the original database file Updating user copies with new front end versions Performance tips for split databases Using search forms instead of displaying all records Setting up data entry forms to optimize speed Avoiding aggregate functions in large split databases Using Top X queries to limit returned records |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||
| Keywords: TechHelp Access split database splitting front end back end linked table manager linked tables share database sharing database PermaLink Split Your Database in Microsoft Access |
