Forum Discussion
Microsoft Access Version Comparison Matrix
- 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.
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.
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.
Unfortunately, Access Web Services have been deprecated from O365. On-premises Sharepoint sites will continue to support AWS through at least the next version, but who knows what will happen after that.
"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. "
Aren't those one and the same thing conceptually? Once you have created tables and exported to SharePoint, you then link back and consume those lists as linked Access tables.