One of the most common uses of Microsoft Access is in data integration projects. Because Quickbooks is so popular, it’s not uncommon for folks to ask me about integrating Quickbooks data with Microsoft Access data. Most of the time, they are seeking to compare and reconcile financial information.

Take, for an example, a nonprofit organization using MS Access as a donor database and Quickbooks for all accounting purposes. Even though the Access application manages demographic information about donors, donor names, giving goals, volunteer activities, etc.. . the donor database also stores monetary donations. These donations should equal all donations recorded in the Quickbooks accounting software.
 
Using Access this way isn’t uncommon at all. Many of my nonprofit clients prefer to record monetary donations in both their donor database and Quickbooks. This gives them a system of checks and balances. In addition, managing monetary donations in two applications helps show accuracy when dealing with auditors or granting organizations. However, this type of donation management also works best when the two databases are integrated. By integrating both databases, it is possible to build reports verifying reported donations balances as accurate.
 
Since Microsoft has been intentional about providing integration tools within Access, it is quite possible to integrate Access and Quickbooks. MS Access already comes outfitted with multiple data connector capabilities. For a Quickbooks integration project, you will need to use the ODBC data connection capabilities. But, first you’ll want to check out CData.com. CData sells 3 different types of Quickbooks ODBC connectors (QuickBooks desktop, QuickBooks Online, and QuickBooks Point of Sale).
 
Once you’ve installed the appropriate QuickBooks ODBC driver, you’re in a position to integrate your production QuickBooks data to MS Access. To link QuickBooks data tables to Microsoft Access go through the following steps:
 

• Click your External Data menu tab
  • Click New Data Source and choose From Other Sources​
    
    • Click ODBC Database. This will initiate an import/link wizard.

• Once you hit the OK button a Select Data Source dialog box will appear. This is where you choose the QuickBooks ODBC dsn file that would have been set up during the install process. I won’t show a picture here, because ODBC dsn files are stored differently on different systems. The dsn file created during the install process will be stored somewhere on your system, and the Select Data Source dialog box makes it possible for you to navigate to that file. If you need help with this step, feel free to contact me.
• Once you select the QuickBooks data source file and hit OK, a dialog box will appear allowing you to select specific QuickBooks tables to link to. For purposes of learning, just choose the Deposit and DepositLine tables.
  • The DepositLine table stores all details of each deposit. If a single deposit is made up of three checks, you will see one record for each individual check in the DepositLine table.
  • The Deposit table consists of one data row per deposit, with the deposit amount, deposit date, etc..

​After linking both the Deposit and DepositLine tables, you’ll be in a position to use queries and compare QuickBooks data to the data you have in your Access database. Let’s go back to comparing and reconciling donor data between QuickBooks and an Access Donor Database and tackle one of the most common reasons this is necessary. When total donor deposits in MS Access don’t match total donor deposits in QuickBooks, it becomes necessary to reconcile deposit transactions in both accounts.
 
If the MS Access donor database is reporting $200 less in donations than QuickBooks, it is important to figure out where the $200 difference is. Because QuickBooks data is now linked to your Access database, it is possible to compare deposit information and find out where the discrepancy is. Experience has shown me the best way to reconcile monetary transaction data is to query the common data by year and quarter. In this example, if deposit data is summed up by quarter, it becomes pretty apparent which quarter is “off” and then the data can be broken down by month, week, until specific transactions which caused the problem are located.
 
In order to sum data by year and quarter, you’ll want use the MS Access Format() function. Specifically, Format([depositDate],"yyyy q") will output a summary of all deposits by a numerical 4-digit year and quarter. Creating recordsets of both QuickBooks and Access donations by year and quarter gives you a way to actually link the data and compare quarterly totals for discrepancies. Once you’ve isolated which quarters a discrepancy occurs in, you can start drilling down into specific weeks and deposits.
 
This article is merely an overview on how to integrate QuickBooks with Microsoft Access. Keep in mind it is possible to use Access data connectors and integrate with multiple databases at the same time. For instance, it would be possible to link to both QuickBooks and data from other sources such as SalesForce, Dynamics 365, or any number of ODBC database sources. 

More Articles About Microsoft Access​​

• Microsoft Access and Data Connectors
• 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
• Do you have questions about your own data management project? Contact Michelle.

Data connectors are the first tool of any integration project. Without data connectors it’s not possible to join information across multiple intelligence sources.
 
Some of the best Microsoft Access features are its built-in data connectors. Microsoft Access was part of the Microsoft Office Suite from the very beginning. Because of this Microsoft has always provided information integration capacities. With just a few clicks it is currently possible to connect to information stored in:

• Other Access database files
• Excel files
• Outlook
• Sharepoint Lists
• dBase Files
• Text or csv files
• Dynamics 365
• Salesforce
• ODBC Databases like SQLServer

 
That Microsoft provides point-click capabilities for data connectivity is no small matter. The ease with which a user can simply connect to data from multiple sources is one of the biggest reasons I recommend Access to clients considering an integration project.
 
Even if you can’t find a native data connector within Access for your data integration project, it is still possible to purchase data connectors. One of the most common ways of joining two data sources is by using ODBC data connectors. ODBC stands for “Open Database Connectivity”. The ODBC interface is designed for industry standard relational databases and is used quite often in integration projects.
 
Most often when my clients need data connection capabilities beyond those built into Access, they need a specialized ODBC connector. When this happens my first stop is CData.com. CData sells specialized ODBC connectors for dozens of specialized software/database products. Following is just a partial list of ODBC data connectors sold by CData.com.
 

• Quickbooks
• Mail Chimp
• Sage software
• Google Contacts
• Gmail
• OData Services
• Google Sheets
• MySql
• SQL Postgre

 
CData connectors don’t just allow users to read information from multiple sources. They also make it possible to edit information. For instance, if you used the CData Quickbooks ODBC connector, you would be able to update Quickbooks customer data from Microsoft Access.  Most of the time folks request integration capabilities it is for the purpose of integrating customer/client information stored across multiple platforms. They may have customer information in Quickbooks, Outlook, Excel, their CRM software and a specialized Access database.
 
The use of ODBC data connectors makes it possible to compare customer contact information across these various platforms and synch customer names, addresses, emails, etc… Of course it is possible to integrate other types of information as well. But integration first requires the ability to connect with multiple data sources. This is why data connectors are so important.
 
To find the native Microsoft Access data connectors just click the External Data ribbon. As you can see there are two groups on the ribbon, “Import & Link” and “Export”. The difference between “import” and “link” is important. When you “link” to external data you will always be accessing production data. “Importing” data merely copies the current information into Access.

Most of the time integration projects require “linking” to production data. During the process of connecting to outside data you’ll be asked if you want to “link” or “import”. If you want production data, choose “link”. If you merely want a one-time copy of the information choose “import”.
 
Start testing with Excel connection capabilities. This will allow you to get comfortable with the resulting wizards. After you’ve played with the Excel connection capabilities, you’re in a better position to start testing and working with more advanced data connectors. Consider all the data sources in your workplace. Which ones would benefit from a data integration project?

More Articles About Microsoft Access​​

• 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 ....
• Do you have questions about your own data management project? Contact Michelle.

There was a time, before computers, when we literally could not get our hands on the data we needed to make decisions. And now, 25-30 years later, we have so much data that we’re drowning in it.

​As technology and software have evolved, the sheer amount of data we have to manage in our work place has increased exponentially. Anymore, it’s not uncommon to have multiple sources of data in any given office.

Common sources of data are:

• Accounting, personnel and payroll systems (not always housed in the same software package).
• CRM Software
  • Business Purpose related software – just a few examples include:
  • Job tracking software used in the construction industry
  • Event management software used in membership driven organizations
  • Inventory management software used in retail, manufacturing, etc..
    • Patient Records software used in clinics, hospitals and other health-care settings.
• Grants management software used in non-profit settings… etc…
• Excel spreadsheets &/or local databases that manage data unique to your office.

One major problem, with so much data, is integrating it. What do you do when you have related data spread across multiple sources? Integrating data from multiple containers can be very challenging. Following are some basic questions and guidelines to consider before starting the data integration process.

• Outline your project objective. Knowing your end objective is very important. Answering these questions will help you stay on track, once you start delving into all the different data sources.
  • Types of reports you want to generate
  • Types of analysis you want to do
  • How often you want to access the data?
  • Who you will share data with?
  • Who will be running reports or doing data analysis?

​

• Understand data source architecture. Related fields are essential to data integration. Best case scenario; you will be able to connect data sets using a common ID Number. But, most of the time you are going to have to use text fields, such as connecting First Name, Last Name fields across multiple record sets. It is important that these related fields be identified as soon as possible.
  • What sources of data do you need to integrate?
  • Who controls those data sources?
  • Do you have access to those data sources? How?
  • Can you do data exports?
    • Do those exports contain the necessary fields you’ll need for analysis?
    • Do those exports contain key fields?
  • Can you get direct access to the data (best case scenario)?
    • ODBC connections to tables.
    • Direct connection to spreadsheets, etc…
  • Document the data source architecture and how different sources are related. A picture is worth a 1000 words, take time to diagram the following:
    • Draw lines connecting related fields
    • Identify how those fields are related

• Determine required fields. Sometimes it helps to actually mockup what you want your final output to look like. This exercise will help you determine which data fields are required in the integration project.
  • If two fields will be linked (for integration) then those fields will be required.
  • If fields are going to be used in calculation, then those fields will be required.
  • Do you need fields to help clarify results? If so, consider these fields required as well.
  • Do you need to create and populate new data fields, in addition to the fields you already have access to?

• Pattern searching and analysis. This is where things can get tricky. The more data sources, and the more end-users entering data, the more issues you will have with data quality.
  • Outline the patterns you will search for to determine accuracy of data. For instance… if you need demographic information on populations served and 15% of the records lack age information, how will you handle this reality?
• How do you determine the overall accuracy of those records? Knowing how you are going to account for missing data – before you start working with the data – is important.
• When looking specifically at the subset of records with null age information, are the rest of the demographic fields populated (ie, gender, ethnicity, income range, etc…)
• Is there a way to infer age from other fields (example a date of birth field)?
• Is the age to date important, or is it the age at the time of service?
• These types of questions are very important. As you go forward with your data integration project, it may become necessary for you to include some kind of explanation on how you managed these types of issues, in your final output.
  • How will you managed related fields, used for linking data. As mentioned earlier, the best case scenario is that you will be linking ID number fields. But, most of the time, my clients have to link text fields. For instance, they have to link two different data sets by first and last name fields. This can run into problems. A typical example is my name. Michelle Meyer is a pretty common name (even if it’s spelled correctly 100% of the time). If you’ve multiple data sets that need to be linked by first and last name – following are a few things you’ll need to take into consideration:
• How comfortable are you that names are spelled correctly 100% of the time. Because once you link first and last name fields, if one recordset has the last name spelled “Meyer” and another recordset has the last name spelled “Myer”, then the two records won’t link.
• Are your recordsets large enough that you have to include a 3rd field to manage multiple people in your database with the same name? For instance, will it be necessary to include an address field, or city field, in the data link?
• Do you need to do some data clean-up BEFORE trying to link multiple data sets? If you’re not confident that data entry is accurate, then it may be necessary to spend some time cleaning the datasets, before integrating them.

Integrating data from multiple sources is possible. It’s the type of project I’m called in to tackle, on a regular basis. But, for the best and most accurate results, it takes planning and fore-thought. The more data sources you have, and the larger those recordsets are the more intentional one has to be in planning an integration project. But, the results of a good integration project are worth the time invested. Data integration projects, managed properly, can give you the data you need to make decisions.​

More Data Management Articles

• 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 ....
• Do you have questions about your own data management project? Contact Michelle.

Problem Outline: Specifically, IHS Alexander developed an MIS system based on MS Access 97 and planned to upgrade to the current version of MS Office. At the time Alex reached out to me, they had upgraded their hardware and migrated to Office 365. Although they had an existing Access database, they did not use Outlook for email.

Before the upgrade, IHS had used Outlook Express (Microsoft Mail) for emails because it allowed them to directly drag and drop email messages into a memo field in their Access database. The entirety of the email body, and heading information would paste to the memo field proving a chronological history of communication with clients or prospective clients.

However, after upgrading to Outlook, they lost drag/drop capabilities between their email handler and Access. Alex emailed me wondering if I could solve this problem. In addition there were other issues which needed to be addressed. IHS Alexander’s existing Access database has been in use for over eighteen years. It is their mission critical database. But, like most mature databases, it needed some revisions to accommodate moving to Microsoft’s newer .accdb file format.

Alex and I began working together in February of 2016. Over the months we’ve tackled many different aspects of his database upgrade. But, the one issue that brought us together was a tight integration between Microsoft Outlook and Access was the most fascinating part of our work together..

Solution Summary: This was an interesting project to work on. Alex outlined the following requirements for drag/drop capabilities from Outlook to MS Access memo fields:

1.  When the user drags/drops an Outlook email to an Access memo field, the routine needs to:
   1. Isolate the sender email address.
   2. Search all contacts in the Access database and find the email sender.
   3. Populate a corresponding ContactID field with the senders correct ID number
   4. Populate the appropriate memo field with both email header information and email body text.
2. The routine must be able to work in four different forms/data entry screens.

The VBA routine to manage Outlook drag/drop capabilities processes the following tasks:

1. If the sender is not an IHS employee, then the routine looks up the sender email address in the Access database contact table. If there is a match, the appropriate contact ID number is assigned to the memo records corresponding ContactID field.
2. The Outlook recipient array designates recipient by either a “TO” or “CC” recipient. My VBA routine uses the recipient type to push recipients into either a “TO” or “CC” line for email header information output.
3. The email subject and time/date received is also extracted from the Outlook email, for use in the drag/drop routine.
4. Finally the body of the outlook email is also extracted, so that it can be included in final output.
5. Once all of the above information is obtained from the Outlook email, then memo output is assembled. In short, formatting of the memo output is as follows:

• Subject line
• Received date and time line
• From line
• To Recipients line
• CC Recipients line
• Email Body

Testing and Revisions: Initial testing of the VBA routine went well. But once Alex rolled it out to production and started testing in the real world, we had to make some revisions. The largest issue we ran into was spacing between paragraphs.

In short, once the VBA routine was rolled out to a production environment, many of the emails were pasting, to memo fields, with too many spaces between lines in the email body. This doesn’t seem like it should be a major concern. However, in reality, if an email is several paragraphs long the subsequent memo output would have 4 to 6 line breaks between each paragraph. This can be a very frustrating situation for end-users just trying to read the resulting memo content.

From my perspective, this was a real puzzle to solve. Because some Outlook emails would paste fine, with just the right spacing between paragraphs. Other emails would paste to the memo field with too many lines. And yet still other emails would paste to the Access memo field with no spacing between paragraphs.

Technically the worst problems to trouble-shoot are inconsistent results. And that is exactly what we ran into with paragraph spacing. After much research and experimentation the VBA script was revised to process the email body a bit more extensively.

Outlook email items have different body formats. Specifically an incoming email may have an HTML body format, a plain body format, or a rich text body format. Part of the paragraph spacing problem was related to different body formats. So, my VBA script was revised to accommodate different types of body formats. Without going into a lot of minutiae, depending on the body format, some of the emails were arriving with extra carriage return characters that needed to be stripped.  

For the most part stripping out extra carriage returns seemed to work. But there is always that one little piece of the puzzle that can throw a monkey wrench into the works. Alex receives email from one particular client that doesn’t process appropriately. Even though this client’s email arrives with an HTML body format, its paragraph spacing wasn’t processing like other HTML body formatted emails. For some reason, with this one particular client, the HTML tags were also generating extra line breaks.

Once I figured out HTML tags were also impacting paragraph spacing, I was able to adjust the VBA script appropriately. The impact of HTML tags is inconsistent, and so difficult to accommodate in the VBA script. At this point the drag/drop routine is working well the greatest majority of the time. There are instances where the incoming emails don’t paste perfectly. But, these instances are rare. So, Alex has asked that we move onto other priorities. 
​
Other Outlook/Access Integration Priorities: Integrating Outlook emails by creating a drag/drop routine for Outlook email pasting to an Access memo field was a new experience for me. This made it a new puzzle for me to figure out. But, Alex also wants me to create integration between is Access contacts and his Outlook contacts. So… this is our next step.

The integration routine I build, for integration of Outlook and Access contacts will have to accommodate multiple employee Outlook contact lists. But, once I am finished building the routines, the following capabilities will be in place:

1. Alex will have the ability to export a .csv file prepped for import into Outlook. This file will be a seed file, used for purposes of starting with a clean and updated Outlook contact list.
2. The .csv file includes the Microsoft Access contact ID for each individual. Once this information is imported to Outlook, there will be a way to update outlook contacts directly from MS Access.
3. Alex and his staff only make changes to contact information from one form. So, all update, create and delete routines will be managed from this one, main Access contact form.
4. Since each employee has their own contact list, I will build routines that update Outlook contacts when an employee opens the database. Specifically my routines will only update Outlook contacts by an edit date on the Access contact record. This should limit the number of Outlook contacts that need updating or deleting when an employee opens the database.

Summary: As Outlook integration projects go, this particular project has been exciting because of the drag/drop capabilities. This was my first attempt at building drag/drop capabilities between Outlook and MS Access. Alex has been a wonderful collaborator. He does a great job itemizing priorities, testing work that I’ve completed, and providing needed feedback. He also has a realistic expectation of the process and so, we can discuss the drawbacks and benefits of multiple options. Alex engages well with these conversations. It is because of his willingness to participate in the give and take of a collaborative working relationship that things have gone so well.

More Data Management Articles​​

• 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.

​Most work places use multiple software solutions. The different software platforms may share related data, but it’s almost impossible to pull the various data sets together for analysis. And then, beyond the software solutions, there are all those spreadsheets with related data.

At some point it almost becomes overwhelming. You have all this data, out there (floating around in the cloud), but no way to really bring it all together. I see this problem, all the time.

One of the best products, on the market, for data integration is Microsoft Access. Access has a lot of advantages over other integration software products. Firstly, MS Access is part of the Microsoft Office suite. This means that it has been cultivated (for over 20 years) to work fluidly with other Microsoft products. Specific to integration, Access can link up to, and share information with:

1. Microsoft Excel
2. Microsoft Outlook
3. Microsoft SQL Server
4. Microsoft Sharepoint Lists

In addition, MS Access can also linkup to data from the following data sources:

1. Other ODBC Databases, such as MySQL, etc…
2. Text Files
3. XML Files
4. dBase Files

At first the idea of linking data from multiple data sources may be overwhelming. But, it really isn’t all that hard, once you figure out how to do it. Following are some basic guidelines when using MS Access to integrate various data sources.

Primarily – with MS Access – there are a couple ways to work with external data. The first is simply importing the external data. For instance, you can open up one of your proprietary software applications and run an export file. Then you can import that file into MS Access. Since Access can read and import common text or Excel files, importing data into Access from other software packages is very doable. But, there is another option as well.

With Microsoft Access, instead of importing data that has been exported from another software; you can actually link the other data source directly to Access. This allows you to read “live” production data.

If you open Microsoft Access and click on the External Data ribbon, you will see a group of ribbon commands labeled, “Import & Link”. These are the commands you want to play with, in order to fully grasp all the possibilities for integrating your various data sources. Each ribbon command tool comes with wizards, to walk you through the various steps.

To begin with you may simply want to play with exporting &/or linking data from Excel. Access and Excel work quite well together, as they are both part of the Microsoft Office Suite. The most important thing to remember, before you start working to import/link a spreadsheet, is to prep the spreadsheet. You’ll want to make sure there are column headings and that the spreadsheet is straight data (without sectioned data, etc…) But, after you’ve prepped your spreadsheet, simply:

1. Open up an Access database
2. Click on the External Data ribbon
3. Click the Excel command tool on the Import & Link group
4. A wizard will pop up.

• You will be able to use a navigator and select the spreadsheet you prepped.
• You can choose to import data, append data to an existing table, or link data. --- Stay away from appending data to an existing table, until you’ve played with the other options. Once you’ve played with importing and linking – you’ll feel more comfortable selecting the append option. (Do keep in mind, if you append to an existing table, you’ll want your spreadsheet data to be formatted so that it is compatible with the table you append to.)

Once you play with the differences between importing and linking data (with Excel) then you’re in a better position to start working with some of the more sophisticated data sources. To import/link data from a SQL database, you’ll need to learn how to work with ODBC data sources. ODBC connectors simply define connection strings to the database you want to read. To learn more about ODBC data sources check out this article. You’ll want to follow the instructions on adding an ODBC data source before trying to import/link to a SQL database.

After setting up an ODBC data source for the SQL database you want to connect to, then the wizards in Access can walk you through the various steps. Just make sure to save your ODBC data source in a network folder that you can find, when going through the import/linking process.

Learning how to import &/or link external files to Access, may take a bit of time. But, once you’ve figured it out, you really are in a better position to bring multiple data sources together and synthesize the data. Access comes with the ability to create queries, bring multiple tables together, relate those tables by common key fields and analyze the data. You can also build custom reports and graphs.

These guidelines provide a basic outline of possibilities. Once you start playing with the various import/link commands and wizards, you may have further questions. Feel free to send me a LinkedIn message, if you’ve further questions.

EDIT - 11/09/2016

Microsoft published some great news this past week. Microsoft Access now included in Office 365 Business and Business Premium with new enhancements. Specific to the topic of data integration, included in the Microsoft announcement, is the following:

From a data integration perspective this is great news. For instance, if your organization uses Salesforce, you will be able to link directly to Salesforce data from MS Access. And Microsoft says this is "just the beginning, there are even more new data sources on the way".

​Microsoft is taking Access to a new level as a data integration tool. I've worked with MS Access for over 20 years. I've helped businesses and organizations in all sectors of the economy manage that unique "local" or "native" data that doesn't quite fit into their software applications. Microsoft's announcement that Access will now be included in O365 Business and Business Premium shows a new commitment to MS Access. Microsoft's efforts to include new data sources shows they are listening to the needs of their customers and understand the distinctive niche that MS Access holds in a workplace. All around Microsoft's latest announcement is wonderful news. Stay tuned, from the looks of things integrating your in-house data is going to start getting much easier.

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.

Email Capabilities

Email capabilities are one of my client’s favorite ways to integrate with Outlook. Their Access database usually contains a lot of email addresses. And although email capabilities aren’t the primary reason for their database, they do have a need to send both individual and group emails. Integration between Outlook and Access for email purposes is very doable. You can:

1. Send emails directly from MS Access. Do you already store names and email addresses in your Access database? If so, it is possible to send both individual and group emails directly from Microsoft Access.
2. Read Outlook emails in Microsoft Access. How often do your emails contain correspondence directly related to specific contacts in your database? It is possible to see related email correspondence in your Access database.

Outlook Contact Management

Every database has contacts. And it’s not uncommon for folks to try and manage their contacts in multiple places. They keep a list of contacts in Outlook, but also maintain a list in at least one database, or Excel Spreadsheet. Because Access and Outlook are fully integrated, you can manage your contacts in one place. If you change contact information in Access, Outlook can be automatically updated. If you add a new contact in Access, it is possible to automatically add the contact to your Outlook address book.

Outlook Task Capabilities

1. If you are managing jobs, tasks, activities in your Access database, it is possible to tap into Outlook’s capabilities in this area. You can:
   1. Add new tasks to Outlook, directly from Access.
   2. Edit existing Outlook Tasks from Access
   3. Delete existing Outlook Tasks from Access

Outlook Calendar Capabilities

1. Again if you are managing jobs, tasks, activities in your Access database, it is possible to tap into Outlook’s calendar capabilities, you can:
   1. Add new calendar appointments to Outlook, directly from Access.
   2. Edit existing Outlook appointments from Access
   3. Delete existing Outlook appointments from Access

The Microsoft Office Suite is almost 25 years old. I’ve been working with the Office Suite for over 20 years. Even in the early days of Microsoft Access, it was possible to integrate some capabilities between Access and Outlook. But, over the years, integration capabilities have evolved to handle some pretty complex demands.

Folks complain about the limited calendar capabilities within Access. Why should Microsoft rebuild calendar capabilities within Access, when it is possible to fully integrate the Outlook Calendar with an Access application? If Access is better at tracking data, Outlook is better at managing email, task and calendar requirements. It’s simply a matter of using the right tool for the job. And since Microsoft is intentional about building integration capacity between its Office Suite products, it makes no sense to duplicate calendar capabilities within Access.

Access has the upper hand when it comes to flexibility. It is not possible to build the kind of complex data tracking and report writing in Outlook that can be accomplished in Access. It’s not uncommon for me to get called into a situation where someone is trying to track specialized data in Outlook, because they like the email, contact management, and calendar capabilities. But, Outlook can’t fully track specialized data. It’s not possible to do any serious report writing in Outlook. So folks end up feeling frustration.

The solution is to integrate the best capabilities from both products. Build an Access database that can read and edit contact information, but also manage distinctive data related to those contacts. Tap into Outlook task and calendar capabilities from within Access. This way you can link essential data related to appointments and tasks that is only available in your Access database. You can build reports that incorporate the Outlook appointments and tasks alongside the specialized data that you store in Access.
​
It has never been necessary to choose one product over the other. But as the Microsoft Office Suite evolves the integration capabilities have only grown. Because integration capabilities are more robust than ever before, I increasingly find myself encouraging clients to use these capabilities. It increases workflow and efficiency in the office, and it only makes sense.

More Data Management Articles

• 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.