Forum Discussion
Microsoft Access Version Comparison Matrix
Microsoft Access debuted in 1992 and recently celebrated its 25th Anniversary! Over the decades, Microsoft Access evolved with a large number of enhancements, database formats, and discontinued features.
It's hard to remember all the changes. We created a page that shows the different Microsoft Access versions and changes in an easy to understand comparison matrix.
Microsoft Access Version Features and Differences Comparison Matrix
See when versions were released, their latest service packs, database formats, linked tables, field types, security features, Windows Operating Systems, and many other features both new and old.
Hope this helps. Let us know if we missed anything.
- Hi Colleen,
Let's address this piece by piece. Access wasn't part of Office until Access 95. Please see this Wikipedia page for details on the history of Microsoft Office. https://en.m.wikipedia.org/wiki/History_of_Microsoft_Office
I undrstand the issue of file names in 8.3 format with dBase and Paradox, but what does that have to do with Access? It's reports are inside the Access mdb file and not subject to 8.3 limitations. You can name a report with much more flexibility.
For "Access Services", do you mean Access Web Services? The latter is deprecated on Office365, but remains supported in on premise SharePoint for the current and next release. Those Apps were never comparable to Windows based versions of Access solutions.
- Great resource, Luke!
- Colleen KayterBrass Contributor
Only one small error in this matrix...
Access 1.0/1.1 were distributed as freebies in Office Suite boxes. I remember installing and using Access in 1993. I worked for an environmental consultant where users were frequently overwriting reports because the 8.3 filename was a limitation they couldn't seem to work around.
I was a bit of a database noob, although I had worked with Dbase III and Paradox. In Access, I created a simple Access table in which users would grab the next 8-digit autonumber as their filename, with their initials as the 3-char extension (making it easy to identify authors and find one's own files). The table included the date, the client, the project, and a description of the document, making it quick and easy to query for any particular document.
And one omission...
What is the status of Access Services for SharePoint Online? Microsoft announced several months ago that this interactivity between Access and SharePoint lists is being deprecated and they recommend using PowerApps/CDS instead. This makes me hesitant to build in Access when clients want to use their SharePoint site.
- George_HepworthSilver Contributor
I just want to add on to Luke's comprehensive summary by pointing out that using SharePoint is not an either/or choice when considering Access solutions.
Leaving aside the issue of discontinued attempts to "webify" Access with first, Access Web Databases in the 2010 version, and Access Web Apps in the 2013 version of Access, Access itself is, and remains, a Desktop database development tool. In a way, we can think of Access Web Services as a sort of side-channel that diverged from the main stream and eventually petered out in a swampy wetland....That main channel, Access, has evolved over the versions but basically it remains what it always was, a development tool to create all three primary tiers in a small to medium sized database application.
Access forms and reports make up the presentation tier, through which the user has visibility to, and the ability to interact with their data.
Access VBA and macros make up the logic tier, in which the application is designed to manage and manipulate data and perform logical operations on that data.
And Access also includes, free, a database engine, ACE, which performs the function of data storage.
The other thing to remember is that Access ALSO can connect to an enormous variety of other data sources, including SQL Server, Oracle, and so on, as well as text files and Excel files. And that brings us back to SharePoint. One of those data sources is SharePoint lists. This has been part of Access since the early days of SharePoint and remains a viable option today. In other words, while SharePoint is not a platform for running Access or Access application, Access itself can consume SharePoint lists just as readily as another data sources.
So I would not have any hesitation to consider Access as the primary go-to application development platform for huge variety of data management solutions.- Colleen KayterBrass Contributor
Access has been my choice for data management for years, but I now have clients with limited/non-existent in-house tech support, and the need to enable external users and virtual teams to view/edit data. SharePoint Online and Access Web Services would be the ideal solution.
I don't want Access to be able to consume SharePoint lists. I want to build data tools in Access and publish to SharePoint Online, converting Access tables to SharePoint lists. There are some limitations that constrain the design process, but still easier than building relationships between SP lists natively.
- LukeChungBrass ContributorHi Colleen,
Let's address this piece by piece. Access wasn't part of Office until Access 95. Please see this Wikipedia page for details on the history of Microsoft Office. https://en.m.wikipedia.org/wiki/History_of_Microsoft_Office
I undrstand the issue of file names in 8.3 format with dBase and Paradox, but what does that have to do with Access? It's reports are inside the Access mdb file and not subject to 8.3 limitations. You can name a report with much more flexibility.
For "Access Services", do you mean Access Web Services? The latter is deprecated on Office365, but remains supported in on premise SharePoint for the current and next release. Those Apps were never comparable to Windows based versions of Access solutions.- Colleen KayterBrass Contributor
My apology for the confusion. I was waxing nostalgic about the problem (documents with 8.3 names) and the solution I devised using Access (generating unique filenames and a searchable index) back in the Win 3.1 days. BTW, Luke, if you check the Wikipedia article about Access, 2.0 was included in Office 4.3 (for Win 3.1). https://en.wikipedia.org/wiki/Microsoft_Access I recall getting Access 1.0 that way, but I could be wrong.
The matrix does mention 1.0 and 1.1 and although they were not "official" Office apps, they were distributed with Office and that is probably how many people were introduced to the single-file database concept.
As for SharePoint... I am referring to Access Web Services for SharePoint Online (Office 365 service). On premise would be a nightmare for my clients who work mostly with virtual teams, external guest users, etc.
- LukeChungBrass ContributorHi Colleen,
Let's address this piece by piece. Access wasn't part of Office until Access 95. Please see this Wikipedia page for details on the history of Microsoft Office. https://en.m.wikipedia.org/wiki/History_of_Microsoft_Office
I understand the issue of file names in 8.3 format with dBase and Paradox, but what does that have to do with Access? It's reports are inside the Access mdb file and not subject to 8.3 limitations. You can name a report with much more flexibility.
For "Access Services", do you mean Access Web Services? The latter is deprecated on Office365, but remains supported in on premise SharePoint for the current and next release. Those Apps were never comparable to Windows based versions of Access solutions.