​Like MS Word and Excel, Microsoft Access has tricks for searching and navigating records. Following are some of the more commonly used filtering capabilities and keyboard shortcuts.

Searching Records
When searching records in MS Access, use the Right-click popup menu.

Basic Quick Filters:

Navigation Within a Single Record

Tab key: Moves cursor forward in the textbox order.
Shift + Tab: Moves the cursor backwards to the preceding textbox.
Esc: Use the escape key to undo an edit.

• Hitting escape once will undo your edit in the current field.
• Clicking the escape key twice will undo all edits to the current record.

Shift + F2 Function Key: Opens the zoom box

​F4 Function Key: Opens drop-down lists

Navigation Between Records
​
Enter: Using the enter key will take focus to next line or next record.
Ctrl + PageUp: Focus moves to the next record.
Ctrl + PageDown: Focus moves to the previous record.

Ctrl+ (Plus Key): Using the Ctrl and + keys together takes focus to a new record.
Ctrl + “ (Ctrl + Quote key): Copies value of same column in previous record

Miscellaneous Shortcut Keys

Ctrl + P: When a report view is open in your window, Ctrl+P opens the Print dialog box.

Alt + F4 Function Key: Closes the entire Access Database

If you’ve any other questions about navigating your MS Access Database do feel free to contact me.
 
For More Data Management Articles See:

• Using Microsoft Access for Data Evolution Projects
• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....

​Are you interested in learning Microsoft Access? Download the sample Northwind Access database. Microsoft built Northwind as a fully functional and fictional database, you can explore, test and learn about the following:

TABLES - Store your data in tables

In Microsoft Access tables are used to store information. Unlike spreadsheets, Access is a “relational database”. This means associated data sets can be linked together through table relationships with referential integrity, including cascade update and cascade delete.

Properly established referential integrity eliminates many problems experienced using spreadsheets for data storage. For example, very often spreadsheet applications must be reproduced for every reporting period. This is simply not necessary in a relational Access database with correct table relationships. Properly built table relationships make it possible to store information across reporting periods in the same database.

See the following diagram to explore Northwind tables and table relationships.

FORMS – Work with data through forms
​
Most people refer to database forms as “screens”. Microsoft Access forms are a user’s connection to the data. Although it is possible to enter and edit information within database tables, this is not advisable. Forms are used to control how users see, work with and manage the data. See the following diagram for more information.

REPORTS – Microsoft Access has excellent report capabilities

You can find the Northwind reports by choosing reports in the left-hand navigation pane.
​
It is possible to integrate reports into form functionality. This way end-users can get to the reports they want through their data interaction screens. To see an example of this, see the following diagram:

QUERIES – Analyze and search data with queries
​
Microsoft Access queries allow you to work with raw data. Using queries, it is possible to create views of information from multiple tables. See the following diagram for details:

The suggestions included in this article give a good over-view of what you can find in Microsoft’s sample Northwind database. Suggestions listed above are merely a start. As you can see, Northwind includes many forms, reports and queries to explore. Microsoft Access is like any other Office application. You can build customized applications for your own needs, Northwind is only one example of how to use Access in a professional environment.

As you dig further into Nortwind, you’ll discover the Create menu bar. Check out the wizard tools for queries, forms and reports. Play with these wizards to learn about building your own queries, forms and reports.

Northwind is an excellent tool for acquainting yourself with Microsoft Access and its user-friendly data management capabilities. By exploring database objects like forms, reports and queries you will learn how Access is designed to manage information. By testing with create wizards, you will learn the basics of building an Access application for your own professional data.

If you’ve any other questions about the Northwind sample database do feel free to contact me.

For More Data Management Articles See:

• Using Microsoft Access for Data Evolution Projects
• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....

​Yes, you can use Microsoft Access as a frontend to your MySQL database. MS Access is not limited to pairing with Microsoft SQL Server.
 
Microsoft Access is an exceptional tool for building user-friendly database applications. Access is one of the top selling rapid application development tools on the market. The programming tools Microsoft includes in Access mean less code writing. This reality just simply saves programming time. In addition, average users can learn to do basic things with their own data because they can use wizards instead of writing code.
 
However – there are still a lot of misconceptions about MS Access capabilities. One of the biggest misconceptions is that Access can only be paired with Microsoft products like MS Excel or SQL Server. These misconceptions are just simply false. One of the things that makes Access such a great user-friendly data management tool is its ability to integrate data from a wide variety of sources. Your organization is not limited to using MS Access with only Microsoft products.
 
It is not uncommon for smaller organizations to use open-source data management tools. MySQL is one of the more often used open-source database applications. And – yes – you can use MS Access with MySQL. Following is one example of how a small organization might make use of pairing MS Access with MySQL.

Why use a SQL Database?
 
Firstly, it’s important to understand the relationship between MS Access and SQL Databases. Data management projects have multiple components. One of the most important aspects of managing data is where and how the data is stored and secured. The easiest way of storing data is to use a spreadsheet application. Information is simply inserted spreadsheet columns.
 
However, as information complexity and volume increase more robust data storage capabilities are needed. That is why databases are so important. Databases make it possible to store information in a relational table structure. They use multiple tables to store associated information. Data tables have relationships with each other allowing for enforcement of referential integrity between tables. For example, a relational database structure makes it possible to enforce cascade update between joined tables such as updating related customer orders when a main customer record is updated.
 
Microsoft Access is a relational database. You can build tables within Access and you can set up relationships between associated tables. Yet, Access tables are not nearly as robust as SQL for storing table. Access cannot store the same volume of data as SQL. Nor are Access tables as secure as SQL tables.
 
The next step up the evolution of data management is to move data to a SQL backend and use MS Access for the frontend user interface. Access is exceptional when it comes to building data entry forms, reports and queries. There isn’t a better desktop database solution for building user-friendly frontend applications than MS Access.
 
By linking MS Access to MySQL tables, it is possible to have robust data storage capacities married with robust user interface capabilities. In addition, this model allows for additional hybrid capacities. Using a SQL backend means it’s possible to build web-facing applications as well. In the end SQL gives an organization more flexibility and expanded data accessibility.
 
How to Use MySQL in Conjunction with MS Access
 
To use MySQL with MS Access you must first import all your data to MySQL. Then once the data is in MySQL you can link the MySQL tables to your MS Access frontend. Following is a general overview of setting up a hybrid MySQL/Access application. The over-view is meant for education, rather than step-by-step instructions.

• Create the MySQL Database: If you already have an Access database, you’ll want to use the Access export features to get your data into MySQL. Before exporting Access data, you’ll need to set up your MySQL database. This can be done on your in-house server, or you can use MySQL tools that may already be installed through your website hosting solution. The advantage of using a MySQL database already integrated with your web hosting service is that the data will be available for web-facing applications. To build a MySQL database through the web host:
  
  • Find MySQL Databases on your web host control panel. Use this capability to create a new database.
    
  • After the MySQL database is created, look for phpMyAdmin on your control panel. phpMyAdmin is the user interface. It is here that you’ll be able to interact with your database, see all database tables, manage the various table columns, primary keys, table relationships, etc. 
• After creating the MySQL database, download a MySQL ODBC Connector. This connector is very important. It serves as the vehicle to connect your MS Access application to the MySQL database.
• Once you've downloaded the MySQL ODBC Connector, search your start menu for ODBC Data Source Administrator. Use the ODBC Data Source Administrator to set up a connection to your new MySQL database. You’ll need to enter the server (your website address), database user name and password. Store the ODBC Connection file on your network.
• Now that you’ve created a MySQL database and corresponding ODBC Connection file, you are ready to export your MS Access data into MySQL.
  • Create a copy of your MS Access database as a backup.
  • Open the Access database and bring tables up in your left-side navigation pane. Then follow the instructions below:

​Moving data to MySQL is a full fledged migration project. The steps outlined above are merely an overview of the process. For instance, once tables have been exported to MySQL, there is real work in making sure all primary keys are properly set, table relationships are in place, table column data types are properly checked and set, etc.
 
Migrating your data to MySQL has a lot of advantages. You will be upsizing the data storage capacity of your database. In addition, if you host your MySQL database with your web host, you’ll be able to access the data through a web interface.
 
But, like any other data migration project, you may find it necessary to rework some of your Access forms or reports. Putting the data in an off-site SQL database means your forms, reports and queries must be efficient. If forms, reports and queries are not built to high efficiency standards, you will get a slow-down in performance. Migration projects can be very successful, but they must be done properly for end-users to feel the full benefit.
 
If you’ve any other questions about migrating your data to MySQL do feel free to contact me.
 
For More Data Management Articles See:

• Using Microsoft Access for Data Evolution Projects
• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....

​Data evolution can be related to data integration, but it contains other components. Unlike data integration projects, data evolution projects build a new core database from multiple sources of data. Typically information from spreadsheet applications or various database/software applications is actually merged into one dataset. The goal of a data evolution project is to decrease the number of data sources and increase efficiency.

​Integration techniques may be used to interact with sources of information that cannot &/or should not be merged into the new core dataset. Most often, when I work on data evolution projects – it is Outlook we use integration techniques with. But, other examples of data sources which aren’t merged into the new core database are Quickbooks/accounting software and CRM or other enterprise data solutions.
 
As an example of a typical data evolution project let’s look at a project for a simulated architectural firm. ABC Architects may start out with the following data sources:

1. Mailing lists – housed in Excel
   1. Multiple mailing lists across multiple sheets in the same workbook
2. Bid - Proposal Data housed between Excel and Access and word
3. Job Data housed mostly in Access – some in Excel
   1. Employee Time Data – housed in Excel
4. Vendor Information – housed in Access
5. Contact Lists housed in Outlook

Instead of five different data sources to manage the processes of marketing, proposals, job tracking and employee time information as affiliated with job tracking – a new comprehensive database solution will pull all data into one location. Outlook contacts will be updated regularly from the new database. In addition users will be able to email contacts directly from the new database.

Because Microsoft Access and Microsoft SQL are built to work with other Microsoft Office products, they serve as an excellent vehicles for data evolution. MS SQL does a superb job of storing large volumes of data. Microsoft Access is the best "rapid application development" tool on the market. It is possible to combine SQL and Access to build robust core database applications. There are a lot of other technical reasons that Microsoft Access is the “go to” product for on premise database solutions as well. But, let’s focus on how MS Access looks and feels when a data evolution project is complete. Since pictures are “worth a 1000 words”, following are some screen shots demonstrating what a complete ABC Architects data evolution project might look like.
 
In the Beginning

ABC Architects manages multiple mailing lists with a spreadsheet application. Each mailing list has its own spreadsheet within an Excel Workbook, as shown below:

ABC Architects experiences the following problems with their mailing list workbook:

1. Edits to same contact records shared across multiple mailing lists are cumbersome.
2. Data volume is pushing the limits of MS Excel. Since the Workbook application is several years old, the size of the workbook is forcing ABC Architects to pull some of the larger spreadsheets out and put them in their own workbooks. This makes maintenance even more cumbersome.
3. Analyzing information across multiple spreadsheets and workbooks has also become increasingly difficult. Spelling errors or variances of same individual names and addresses makes it impossible to trust analysis of 1000s of records for common contacts.

 
In addition to the above problems with the current Excel mailing list solution, there are also vendor companies and contacts in an Access database. Contact information is also stored with Bids & Proposals; it is stored with Job Tracking, with Vendors and also in Outlook. All this contact information shares common data points, Organization names, First Names, Last Names, Email addresses, Phone numbers, Street addresses, etc. By merging all contact information into one core file it will be easier to maintain, analyze and query the data.

After Evolution
 
The following screen shots show how some of the elements in a core ABC Architects database solution might look.
 

​Main Dashboard:

​The above screen shots are simply examples. And they don’t encompass all that an evolved data management solution can do. For instance, in the example of ABC Architects, users can also work with bids and proposals, job tracking, invoicing, and do mass emailing directly from the core Access database. In addition integration with Outlook is built in so that Outlook contacts are updated when contacts in Access are edited. Users can email from Access and if they want to add a logged activity to the Outlook Calendar they can do that as well.
 
These are the advantages gained when data is evolved from multiple sources into one core Microsoft Access database. Nothing ever stays the same. That includes our work environments, work teams, clients, vendors, and the information needed to effectively manage our ever changing organizations.

• How many data sources are you managing?
• What types of information is shared across those data sources?
• How much work is it to keep same records in multiple data sources updated?
• Does your team trust the data in all data sources?

 
Answers to these questions can guide you to a more effective data management solution.

More Articles About Microsoft Access​​

• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....
• Do you have questions about your own data management project? Contact Michelle.

In 2014 I wrote the LinkedIn article: If you're looking at OFFICE 365, and you use Microsoft Access, look harder. At the time, Office 365 fell short of my expectations, mostly because of its treatment of MS Access. Initial publicity about MS Office 365 promised the ability to move MS Access databases to their cloud server. But, as my clients moved to Office 365, we discovered Microsoft promises of cloud capabilities for MS Access were inadequate. Complex Access databases could not be used from the cloud platform without major revision.

​Over the years folks have asked me about using MS Access in a remote environment. In time, using a remote desktop setup surfaced as the best remote environment solution for MS Access.

Why deploying MS Access to an online Sharepoint site does not work

In theory it is possible to build and maintain MS Access applications on a Sharepoint server. However, in this case, theory is contradicted by reality. The basic reality is most MS Access databases use at least some VBA (Visual Basic for Applications) coding. Complex MS Access applications use a LOT of VBA coding. Bottom line: no online environment (including Sharepoint) supports the VBA language.

MS Access applications with VBA coding will not work in the Sharepoint environment. Since any complex MS Access application uses VBA – it is not realistic to say the application can migrate to Sharepoint. This VBA restraint is not limited to Access application. It also affects complex Excel applications using VBA script.

Microsoft tried to address this issue by driving development to MS Web Apps, which made use of Macros (instead of VBA). This push caused much frustration because macros are not nearly as versatile as writing actual VBA code. VBA is a language. Those of us who make use of it, know how to use the language. And just like English, we can use the VBA language in complex ways and create some really intricate applications. Forcing one to move from the versatility of a language to the simplicity of macros meant giving up the ability to build intuitive applications that met the complex needs of our users.

Frustrations with Microsoft’s push away from using VBA were pretty universal. Concerns ran so deep, that many folks in the business community began to wonder if Microsoft was beginning the abandonment of MS Access. If true, this reality had major implications for professionals across all sectors of the economy. MS Access is the top selling desktop database application on the market. In comparison to web side coding, Access gives professionals the ability to roll out data management applications rapidly and cost effectively. Abandonment of MS Access would mean a sharp increase in data management costs and Microsoft consumers were justifiably concerned about the matter.

In addition, professionals were also feeling irritation with Microsoft’s overall push towards a “cloud first” business strategy. Most businesses and organizations use the cloud. But, like any other tool, they prefer to use the cloud the way they want to use it and when they want to use it. They do not relish being pushed into the cloud and very often make intentional decisions to keep their data off the cloud.

In credit to Microsoft, they heard the dissatisfaction of their customers. Late last year Microsoft came out with an announcement which eased fears about abandoning MS Access and their willingness to embrace a reality where professionals drove the use of cloud, instead of Microsoft.

So… How should professionals use MS Access in the cloud?

Since Sharepoint does not support the VBA language, it is best to run MS Applications in a remote desktop environment. Remote desktop environments actually allow the desktop you see on your own computer to be run in a remote environment. If you’ve ever logged into your own desktop from home, you’ve logged into a remote desktop set up.

It is possible to setup more formal remote desktop environments for the purpose of accommodating MS Access applications. As an example, one of my clients have used MS Access for around 20 years. Over the years, their mission critical database evolved from five different MS Access database applications. The original applications used Access tables. The various databases were used for different purposes but shared similar data.

Over the years, we did the work of merging functions from the original five databases into one core database. We also did the work of migrating all data from Access tables to SQL tables. However, remote Access to their database continued to be a problem. This client needs to move their entire office to a temporary location once a year. In addition, it is not uncommon for staff members to travel. Both of these realities require remote access to data.

This client moved their mission critical Access application to a remote desktop environment. Since the migration to a formal remote desktop setup, they have been very happy with the functioning of their database. The speed is better than it was before, they can login to their database from any computer with an internet connection. It is even possible to login to their remote desktop from their smart phone.

I have tested more formal remote desktop applications myself, and been quite impressed with the capabilities. Especially the speed. Over the years I’ve logged in remotely to client’s desktops and am quite accustomed to using a remote desktop setup. But, moving that remote desktop to an off-site service is another thing altogether.

Sometime ago I tested AppOnFly and was unimpressed. My connection kept dropping and when I was connected speed was an issue. The speed issue wasn’t major, but certainly it was noticeably slower than working at my own desktop. In addition the service is not based in America and I was unimpressed with customer support.

I also tested Vyon Cloud Services. Vyon Cloud services are the Quickbooks Cloud Hosting Service. The services are managed in Phoenix, AZ. The first thing that impressed me about Vyon is they are based in the United States. I was also immediately impressed with their customer service.

Testing with AppOnFly was not nearly as user friendly as testing with Vyon. For my purposes, I needed a testing environment set up with SQL Server capabilities and MS Access capabilities. AppOnFly was either not able (or willing) to set up a test environment with SQL Server capabilities.

Vyon support folks emailed me in a timely fashion and asks for my setup specs. They didn’t blink at my need for a test environment with SQL as well as Access. The test environment was operational within 2 business days. In addition, when the test environment was fully set up I received an email with a human name, a human email address and an introduction as my “technical point of contact”. This did not happen with AppOnFly (and like so many IT consumers I’ve almost stopped expecting real human contact when dealing with technical services).

As to the performance of VyonCloud, I was quite pleased. The speed was exceptional. I was able to work in SQL Server Management Studio and MS Access the same as if they were sitting on my own computer system in my own office. VyonCloud pricing is very competitive and the customer service makes it an outstanding choice in my book.

Another remote desktop option is Amazon WorkSpaces. I’ve not personally tested Amazon WorkSpaces, but many of my clients use Amazon. VyonCloud impressed me with its customer service and technical capabilities. So… I have to confess I felt no need to test further. But, the clients who do use Amazon are pleased with the service.

Another option for remote desktop capabilities are services offered by local vendors. Some of my clients use locally owned businesses for their networking needs. And those businesses offer remote desktop services.

There are no shortage of ways to migrate your MS Access application to a remote desktop environment. It becomes like any other cloud service you purchase. You will need to compare pricing, quality of customer service and technical capabilities. But, once your MS Access application is in a remote desktop environment you will be able to use it anytime you can get to a computer with internet capability.

 
More Articles About Microsoft Access​​

• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....
• Do you have questions about your own data management project? Contact Michelle.

One of the biggest misconceptions business folks have about Microsoft Access is that it is going away. Many people are under the impression that Microsoft no longer supports Access, or that Microsoft plans to jettison Access altogether. This is simply not true.

I do understand the hesitation. For some years Microsoft had been lukewarm in its development and promotion of MS Access. In fact, in June of 2014 I wrote a review of MS Office and expressed my own frustrations over Microsoft’s treatment of Access.

But in the last 3 to 4 years Microsoft has really changed course. Not only is Microsoft now fully behind Access with support, they have invested in adding new capabilities.
​
Access has always been a top-notch data management product. There isn’t a better tool on the market for managing that unique in-house data that doesn’t quite fit into an organization’s major software applications. My clients like Access for many reasons:

• Access is the best RAD (Rapid Application Development) desktop database on the market. This means it’s possible to build an in-house data management solution quickly and within budget.
• End-users can learn how to do basic things in MS Access, so they aren’t required to call an Access expert for every little thing.
• Access is a fantastic integration tool, making it the go-to desktop tool for integrating data from multiple sources.
• Access has historically been part of the Office Suite. So, it has been built to work fluidly with Excel and other Microsoft products.

Since Access has such a loyal following, many of my clients were frustrated with Microsoft’s seeming disregard for their operating needs. Folks truly wondered how long MS Access would be around and if they needed to start searching for other solutions, knowing full well that other solutions would be costly and that they would lose control over their own data.

But Microsoft really has listened to the frustrations of their customers and stepped up to the plate with new capabilities. Specifically, Microsoft took to heart the need for more data connectors. Data connectors are extremely important in data integration projects.

MS Access is often used to manage data that doesn’t quite fit into an organization’s main software systems. This means users need the ability easily move data back and forth between their main software systems and their supplemental Access database. The new data connectors Microsoft developed makes the job of data integration and communication much easier. Some of Access data connectors include:

• Excel
• ODBC
• Outlook (Integration with Outlook is one of my most common data integration requests)
• Sharepoint Lists
• Dynamics CRM
• Salesforce
• SQL Server
• dBase

These data connectors are exciting because they are concrete evidence that Microsoft understands one of most important roles Access plays in an overall data management strategy.

If you need a cost effective way to integrate data, MS Access is the best tool out there. Microsoft's commitment to new data connectors is not only a technical upgrade; it is also an announcement that they finally “get it”. Microsoft finally seems to understand just how important MS Access is to business’ and organizations world-wide.

Since the 1990s Microsoft has done an exceptional job of creating an integrated Office Suite. Organizations world-wide depend on the Microsoft Office Suite to run their organizations. And, very often, MS Access is a pivotal piece of the puzzle.

When Microsoft started to diminish the role of MS Access in their Office Suite products, they made a lot of their own customers very nervous. With the addition of new data connectors in the 2017 role-out Microsoft signaled to the world that MS Access isn’t going anywhere. Microsoft is investing in a future with MS Access. This should ease the minds of many, many professionals who depend on MS Access to do their job.

================

For more information on using MS Access as a data integration tool, the following two articles may be of interest:

• Case Study: Integrating Microsoft Outlook and Access
• Microsoft Access and Data Integration
• Do you have questions about your own data management project? Contact Michelle.

One of the largest misconceptions about Microsoft Access is that it’s expensive. Many people operate under the assumption that if they build a data management solution in Access, that every user will need a full version of Access installed on their machines. This is a wrong assumption.

​Microsoft provides a runtime version of Microsoft Access. It does not cost anything to download and install Access runtime, on user machines. If your organization builds a multi-user Access application, you would only need to pay for the full version of Access for administrator/developer machines.

Using Microsoft Access Runtime, on user machines, can save organizations a lot of money. In licensing fees, your organization can save an average of $100 per runtime install. Depending on how many machines have runtime installed, $100/machine, can add up to a lot of money.

Runtime has other advantages as well. Where runtime is installed, end users will be more restricted than administrators/developers who have the full version of Access. Following are some of the restrictions on users of Access runtime:

• Users will not have any access to source code. This protects your database source code is one very important reason to consider Access runtime.
• Users will not have direct access to any of the data tables. They will only have access to data through forms, queries and reports created by the programmer. This makes it easier to control what users see and what they are allowed to edit, and how they can manipulate data.

These two advantages make runtime a good choice, even if your organization does not have a high multi-user database count.

Creating a Runtime Version of Your Access Application
In order to create a runtime version of your Access application, you’ll want to take the following points into consideration.

1. Firstly, in order to effectively use runtime, it’s important that your application be a split database application. Split database applications store the actual data in a centralized backend database file. By storing data in its own file, it is then possible to have multiple frontend application files linked to the same data source. It is possible to store your data in its own Access table database, but most often split databases include a backend SQL database for data storage
2. Frontend Microsoft Access file that includes all the data entry forms, reports and queries used by end users.
3. The frontend file is linked to the data in the backend SQL Database. You can read more about setting up a split database in this LinkedIn article. Yes – Microsoft Access works in a Multi-User Environment
4. In addition to using a split database setup, you should also consider taking advantage of Access’ “Trusted Location” settings.Trusted locations are assigned to an Access file, to ensure that it can only be opened from specific file drives. This helps protect your runtime file from tampering. It makes it more difficult from someone to copy the file and change it back to a file that can be opened with a full version of Access.
5. You can read more about Trusted Locations at this link.
6. Once you have a split database, and assigned trusted location(s) to the file, you are in a better position to actually create a runtime file for end-users. Creating runtime files is actually a three-step process.The first step is making sure you retain a copy of your database in an .accdb format. This ensures that you have a “developer” copy available, in case you need to make future revisions.
7. Before actually creating your runtime file, you will want to save/publish your frontend file in an .accde compiled format. This action will protect all of your VBA source code. To save your file in an .accde format follow the instructions in this link.
8. Now that you’ve compiled your database, so that the VBA code is protected, you are in a position to convert that file to a runtime version. To do this you simply change the extension from ACCDE to ACCDR.
9. Now you are ready to roll out the .accdr file to a network folder, where all machines, with the runtime version of access, can open and use the database.

More Articles About Microsoft Access​​

• Yes – Microsoft Access works in a Multi-User Environment
• YES – Microsoft Access Can be Used Securely
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....
• Do you have questions about your own data management project? Contact Michelle.

​One of the biggest misconceptions about MS Access, is that it isn’t a secure database. To be fair, the misconception has some grounding in fact. If the MS Access database is using native tables, then it isn’t any more secure than an Excel Spreadsheet. But, this is a simplistic understanding of the issue. Following are some things to take into consideration, about data security and the use of Microsoft Access.

Many organizations fault MS Access Security, but have no problem with storing sensitive data in Excel spreadsheets, created by end users and stored in folders that may (or may not be) secure. For example – and I see this on a regular basis – users will download sensitive data from a secure enterprise software solution. They’ll dump their export into Excel, save the Excel file to a personal folder (or worse yet their desktop). This isn’t even logical. On the one hand, it’s o.k. for end users to copy/paste spreadsheets of sensitive data to in-secure locations (like their desktops). But, for some reason storing the same data in an Access database (with more controls than a spreadsheet) is forbidden. Even if security in Access was limited to native Access tools, one would have to look long and hard at a policy which allows so much exposure to data through Excel, but then limits the use of Access.

Beyond the obvious problem described above, what most people don’t know – and never get to in their assessment of Access as an option for sensitive data – is that Access can be upsized to incorporate the use of SQL Server. You may want to read this Microsoft Knowledge Base article on upsizing Access Data.
​
From the article:

In short, when you upsize an Access Database to SQL Server, you’re moving all Access tables and data to the more robust Microsoft SQL Server database. Then you link the SQL Server tables back to the MS Access frontend file. This is a very common way to use Access. Most of my clients are using a SQL Server backend database with Access as the frontend file.

In the linked article, Microsoft lists many benefits of upsizing Access data to a SQL Server backend. The linked article is well worth your read. The benefit of Improved Security is highly important. By moving all of your Access data to a SQL Server backend database, you can immediately take advantage of the robust SQL Server Security capabilities. Specifically you can use SQL Server Active Directory Security. This means Active Directory security can be used to:

1. Determine which user is logged into the database
2. Create roles to designate permissions for logged in users. Permissions can restrict which tables users are allowed to see, to edit, etc…
3. In addition – by using Active Directory - ODBC Data Connectors are more secure, because you can get rid of saved login strings with user names and passwords. With Active Directory controls at SQL level, all Access requires is the use of Windows NT authentication – SQL will do the rest.

Beyond using Active Directory Security, there are other ways that one can control access to data. SQL Views can be used to limit which datasets a user sees. For instance users may only need to view customer records for their district. In a situation, such as this, it is possible to write a query at SQL level, which limits the record-set to a specified district. These queries are called SQL Views. Once the SQL View is written and stored it can be linked back to an Access frontend file. This is a subtle way to limit which records a user can view, but it is effective. Where Active Directory settings can be used to determine which tables a user is allowed to edit and which tables they are even allowed to read, SQL views can filter the data a user is allowed to view &/or edit down to a specific subset of records (such as all customers in one district).

By upsizing Access data to a SQL Server database, and incorporating the robust security capabilities of SQL Server, the security problems one would expect in a stand-alone Access go away.

Of course it only makes sense to continue to create restricted run-time versions of your Access frontend file and store these files in a secure folder, with limited access, by qualified users. In addition, when creating ODBC data connectors, you should use machine data sources, stored in secure folders and restricted to qualified users. That way only qualified users; logged into the specified machine, will be able to get to the data source.

Once all of these things are taken into consideration, Microsoft Access can be used very successfully with sensitive data.

More Articles About Microsoft Access​​

• Yes – Microsoft Access works in a Multi-User Environment
• Deploying Microsoft Access in a Remote Environment
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....
• Do you have questions about your own data management project? Contact Michelle.

One of the biggest misconceptions about Microsoft Access is that it can’t handle complexity. In regards to a multi-user environment, many professionals continue to operate under the paradigm that MS Access doesn't work properly in a multi-user environment. This assumption is an unfortunate and costly mistake.

​i’ve worked with MS Access since version 2.0 back in the Mid 1990s. I’ve watched Access go through all the various upgrades and transformations. I also have extensive experience with SQL. From experience I can tell you that Microsoft Access serves many of my clients very well in a multi-user environment. MS Access is a tool. And like any other tool, it has to be used properly. So, there are best practice protocols to using MS Access, but there are best practice protocols to developing in any other database software as well.

Best practice protocols, in regards to Microsoft Access, are not just my opinion as a programmer with 20+ years of experience. Best practice protocols are defined by Microsoft. Generally speaking, if the following issues are addressed properly, MS Access will function very well in a multi-user environment.

Record Locking: Within a multi-user environment, record locking is pivotal. Record locking prevents two people from editing the same record at the same time. In a multi-user environment record locking should be set as follows:

• Default Open Mode – Shared
• Default record locking – Edited Record
• You can find these settings in Access 2010 by going through the following steps:
  • File Menu
  • Click Options
  • Click Client Settings in the left side Options Menu Pane
  • Scroll through the Client Settings until you find the Advanced Settings
  • Set advanced settings as defined above.

Split Your Database: Splitting your Access database will dramatically improve performance in a multi-user environment. Generally speaking splitting an Access database means separating data storage functions from data processing functions. Data storage is managed with tables. Data processing is managed through forms (for data entry), queries, reports and other processing objects. To split a database, the storage component is “split” away from the forms, reports, queries, and reports. After an Access database has been split there will be a backend file (data tables) and a frontend file (data application).

There are a couple of different ways to split an Access database.

1. Data tables can be stored in an Access data file
2. Data tables can be stored in a SQL file

Either way, the data tables are stored separately from the main Access application. The backend tables are then linked back to the main frontend application for data access. Most of my clients operate in multi-user environments and every multi-user client operates off of a split database.

The use of SQL comes into play because of different factors. High volumes of data, high volumes of end-users, network capacity and capabilities all play a role in determining when to use SQL over an Access backend.

Other Considerations

Beyond the technical considerations listed above, following are some observations from my own experience.

Microsoft Access is not the perfect solution to all data processing problems. But, then there really is no perfect solution. By its very nature office data is dynamic, and therefore it requires dynamic data processing solutions.

One of my biggest frustrations with MS Access is that Microsoft really hasn’t developed an efficient means of deploying Access in an online environment. It can be done, but it’s not easy. I was excited when they introduced Sharepoint, because all their literature promised that it would be possible to deploy Access databases on a Sharepoint site. Technically, this is true. But, in practicality it simply doesn’t work, not with complex databases anyway. I have found that Sharepoint can play a role, at best, it’s a limited role. If the backend files are SQL, then it’s possible to harvest data through a Sharepoint form and use that data in Access as well. But, Sharepoint does not have the capacity for complexity that Access has.

If I feel frustration at Access’ limitations with online applications, in most other ways I’ve been pleased enough to continue to use and recommend the software. Access stands up well to all the critics. It continues to be the best selling desktop database application software on the market, and with good reason. It develops faster and less expensively than other options. It integrates quite nicely with Excel, Outlook, SQL and other software products. End-users can learn how to accomplish basic things in Access (like writing their own reports, queries, etc…). It works great in a multi-user environment, if set up properly.

MS Access is capable of highly complex information management requirements. Over the years I’ve developed and maintained database applications that process data from over a hundred SQL tables. This is no small feat and requires a lot from the frontend software. But, when used properly, Access has been able to stand up to all the requirements in the following areas:

1. Complex data entry screens needed to harvest data to the various tables
2. Complex report writing capabilities needed to report off of so many tables.
3. Complex querying capabilities needed to process such a high volume of data
4. Volume of traffic over the network needed to manage a high multi-user environment with a high data load.

MS Access is under appreciated, and under-utilized, in many organizations. This really is too bad; it’s a costly mistake to discard a product simply because of misconceptions and misunderstandings about its capabilities. Since Access develops so much faster than other frontend applications, it is a very cost effective choice for a lot of data processing needs. Not only that, Access is a fantastic tool for data management adaptation and evolution. Data is dynamic. It always has been and it always will be. Because data is dynamic, finding a data processing tool that is flexible is imperative. Access is extremely flexible; it can grow and change with the needs of an organization.

Before you dismiss Microsoft Access as a tool for your organization, take the time to really learn what it can do. You will be pleasantly surprised.

=================

EDIT - 02/26/2016:

​The following is a link to a discussion among professional Microsoft Access Developers about using Access in a deployment of thousands of users. If you want more information about using Access in a multi-user environment, this link is a must read: Can Access 2010 using SQL Server 2012 and RemoteApps (RA, aka terminal services) scale to hundreds/thousands of users?

EDIT - 02-21-2018:

Since writing this article,  some of my clients have successfully deployed Microsoft Access in a cloud environment. An article about Deploying Microsoft Access in a Remote Environment can be found here.

More Articles About Microsoft Access​​

• YES – Microsoft Access Can be Used Securely
• Why You Should Care about RAD and How It Impacts Your Bottom Line ....
• Do you have questions about your own data management project? Contact Michelle.