At this past Ignite conference, our new Microsoft Access Program Manager, Michael Aldridge, hosted a session regarding the new Access Dataverse Connector. I briefly touched upon this in my article Access Session At Microsoft Ignite, Yes It Is True! and provided a link to the recording of the session itself Bringing Microsoft Access into the Future: Introducing the Microsoft Access Connector for the Microsoft Power Platform.
In the session, Michael mentions several times the fact that Microsoft Access was a low-code/no-code solution
and I wanted to touch upon this statement for one moment.
We have to put the comment into the context of the presentation being given (Dataverse which is being promoted as low-code/no-code), but I thought it still brought forth a good subject for discussion. So put away your pitchforks and let’s have a frank look at Access for one moment.
What Exactly Is Low-Code/No-Code?
I know the terms are pretty much self-explanatory, but for the sake of completeness let’s properly define them.
So what exactly are no-code and low-code development platforms all about?
So, Does Access Qualify as a Low-Code or No-Code Platform Then?
Microsoft sure seems to think so.
In the strictest sense of the definition, I suppose it could fall into such a category as it is possible to create a table, form, report all through the Graphical User Interface (GUI). So yes, it can be considered a low-code/no-code development platform and as such, it could be considered one of the predecessors of the currently hyped low-code/no-code buzz word movement. Maybe it is actually one of the founding platforms.
That said, it is noticeably absent from Wikipedia’s low-code development platforms listing. Is that simply an oversight or a purposeful omission, I cannot say.
The Real Question Is Should It Be Termed As Such?!
The answer here is an emphatic NO!
Sure, if you want to position your product in the moments hot buzz words, it makes perfect sense to say so, no doubt about it, but …
Calling Access low-code/no-code is one of the biggest disservices one could possibly do to the product itself and the Access developer community at large. In one brush stroke, you devalued the entire developer community’s worth! Furthermore, in one statement, it falsely, makes people believe they can create what they see others do with a few clicks of a mouse, when most real life solutions require hundreds, if not thousands, of programming (CODE) hours by professional developers! That’s the reality of Access development.
The fact of the matter is that if you use Access in a low-code/no-code capacity, you are using it in a crippled manner and truly not getting the true power of Access working for you! Access’s biggest advantage over almost any of its competitors products is everything it can do through code!!! VBA is where Access’ true power lies.
Just look at the quantity of code on this very site!
VBA
Look at what basic VBA provides to the product:
- Filtering/Sorting
- Form Validation
- Automatic Table Relinking
- Ability To Send E-mails With External Attchments
- Automate Other Applications (Excel, Outlook, Word, …)
- File/Folder Picker
- Get System Information through WMI
- Change Control Properties (colors, fonts, …)
- Open Links
- Display Progress Bars
- and SO much more!
VBA – APIS
Look at all the APIs that are required to do just about anything!
- Username
- Computer Name
- Date/Time Dialogs
- Color Picker
- System Font
- Open/Print Files
- Internalization/Multi-Lingual Solutions
- Manipulate Images
- Drag and Drop Functionalities
- Resizing Form Based on Screen Resolutions
- and SO many more!
Queries
While it is true that Access has a revolutionary Query-by-example interface for developing queries, this only works for simple queries. Even within simple queries, one may need to use the Expression builder and get into programming and using function (making it a low-code). Furthermore, for advanced needs we have to switch over to manually writing SQL Statements (Union queries for instance – making it possibly high-code). Many professional developers automatically switch to SQL View and write their queries entirely by hand.
Macros
Now some may bring up Macros. Firstly, Macros can simply not remotely begin to do everything that VBA allows you to accomplish, so right off the bat you are only capable of doing most basic tasks. I am also a firm believer that by using Macros you are doing yourself a major disservice as:
- The Interface Is Awkward and Much More Spread Out Than Comparable VBA Requiring More Scrolling
- You Can’t Search Macros When You Need to Perform Updates
- They Can Be Very Difficult/Frustrating To Troubleshoot! More so Than VBA.
- In My Experience, They Are More Time Consuming To Work With.
This is why I always tell new developers to concentrate on learning VBA as the ROI is far superior.
Because of Macros limitation, eventually the application will require VBA, so why use 2 different programming languages and make things even more complicated? Start with VBA and do everything in VBA. Centralize your code making it much easier to maintain.
So yes, Access Macros may also fall into this low-code/no-code vision, but for me, are simply not worth the time to even consider being used in any real manner.
The Ribbon
Then there’s the Ribbon. Oye!
Yes, one might think that since we can customize the QAT & Ribbon via a GUI that they are low-code/no-code, but you’d be wrong. Anyone that has ever created, or tried to create, a custom ribbon for their Access, Excel, … solution is that it is all code! Not only is it code, but two different languages are involved: XML and VBA. Worse, Microsoft doesn’t provide a tool to work with the XML so you either use a text editor (because you’re that good) or you need to purchase a 3rd party application.
Is It, or Isn’t It?!
Which brings use back to Is Access low-code/no-code?
Where I will say Access’ low-code/no-code strength shines through is prototyping! One thing I love is that I can, in a few minute, prototype a Form/Report/… to show a concept to a client! But when it comes to then making that same Form/Report/… functional, it normally will take hours of coding and everything else that goes along with development (graphics, …). But for prototyping, Access is OUTSTANDING!!!!
Certain aspects
- Table Designer
- Query by Example Editor
- Form and Report Designers
- Ribbon Customizer
are most definitely low-code/no-code, there is no denying it, but as a whole, Access is a high-code platform. The most basic aspect of any solution, the menu (in the case of Office, the Ribbon) is extremely high-code. Moreover, performing most automation requires VBA and in most solutions considerable amounts of VBA Code! Everything is VBA in Access.
I liken the low-code/no-code of Access to ridding a tricycle where you have to follow the roadway, and high-code to driving an all wheel drive vehicle wherever you’ll like to go. The same is true of Access; don’t use code and you have to follow predefined paths and you have limited capabilities, add code and now the world is your oyster, do as you please!
So no, IMHO, Access is not a low-code platform, certainly not a no-code platform and such statements demonstrate a misunderstanding of Access itself, erroneously set new Access developers up with a false impression and expectations of the application and what it can do out of the box setting them up for considerable frustrations.
What’s your opinion? Is Access a low-code/no-code platform in your opinion? Can a proper business solution be created without the use of coding?
Since you are soliciting opinions, I will offer mine. Although I agree with just about everything you have said, the only part I disagree on is your conclusion: Access IS a low code/no code platform.
There were not the first however. I remember Borland Paradox being the first (that I can recall) and their legendary QBE (query by example). They even had a Personal Developer Module that was a marvel to watch – for me anyway! They were way ahead of their time but failed to evolve – but that is another story.
Access has those same features which MS has perfected over the years making Access a tool that anyone can use to make mildly complex applications.
Of course, as you get more proficient and start thinking in the “what if” mode more frequently, you quickly recognize it’s limitations and start to research. Research that leads you to the wonderful world of VBA and once you walk through that door, there is no going back.
That’s what I think anyway!
George Hepworth has invited Michael Aldridge to the December 2nd AUG Access Pacific meeting to discuss the Dataverse connector (in public beta) for Access. Hopefully he accepts, I would love to hear what he has to say.
J’utilise Access depuis ses premiers balbutiements, à mon avis à l’époque c’était le meilleur RAD sur le marché, je pouvais développer des applications 3-4 fois plus rapidement que VB6.
Donc, NON Access n’est pas une plateforme “low-code/no-code”, c’est une solution complète et de surcroit interfacée avec une base de données SQL ça devient une solution professionnelle!
Le problème intrinsèque d’Access c’est sa réputation!, combien de fois j’ai dû justifier à mes clients mes soumissions comparativement à mes compétiteurs avec des solutions orientées Web ou en Visual Studio.
Il n’ya qu’à rechercher dans Google exemple: “microsoft access form design examples” pour comprendre qu’il y a plus de “newbies” que de professionnel qui l’utilise…
Bref, c’est une discussion perpétuelle sur le VBA et Access….
Hello, I see many of the “low-code/no-code” platforms supports extensibility for professional developers with “code-only” approach as well. This is just highlight of capability of the tool to create solutions by people without programming experience. I think Access excels in that without doubts. As well for many power users there will be much easier to extend/automate via VBA (easy to learn versatile language) rather then bloated Java/C#. At last when you’re professional developer, you discover real power of Access as RAD, hard to compete from invest-get perspective. Hope that Dataverse will fill the gap between low traffic user targeted Sharepoint List and professional Azure SQL/MSSQL with somewhere in between data-centric but still easy to create sollutions.
The RAD power of Access is unbeatable, VBA is quite easy to digest and has a ton of references you can find. If Microsoft or somebody can come up with a way to use native Access with the WEB it will blow the industry apart. Morfik was able to start but was discontinued for an unknown reason.
Microsoft has attempted to go down the Access/Web rabbit hole on 3-4 (depending on how you count) occasions now. In each instance, they just abandoned everything and walked away. I highly doubt we’ll see them try again. Microsoft’s solution now is to migrate your data into Dataverse or Azure SQL or some other RDMS and then build PowerApps, Hybrid databases, .Net solutions, …
Nice observation Dan, but the tenor of your statement seems Access has no future in the web. MS failed and we don’t really know the exact reasons, maybe it’s time for MS to share the Access code to the open source community. For sure many will be interested to study the process how to improve and make Access a commando in desktop and web development. If MS can afford to share .Net/Core in the opensource community why not Access?
Microsoft’s latest approach, Dataverse connector, is now to offload the data to the cloud and use other tools (mainly Power Apps) to build web components for the data and leave Access for desktop consumption.
Hi
Jarek, KEXI project maintainer here, open source MS Access competitor. I see some nice topics here and wanted to say than you. It’s worth considering for KEXI to become more low-code and even no-code in more aspects so I’ve read everything that was published here.
For the high-code part, I believe it can’t be drop out, both worlds shall coexist in a single platform, just like pro devs and power users coexist. For KEXI we got convinced that the code layer will be Python. And that’s planned for KEXI 4.
Such modernization of KEXI, if we succeed, will ride on a cloud-less, non-web postulate, which puts privacy and security advantages first, compared to popular low-code solutions.
The world suffers from the closed nature of MS Access format. It took years to reverse engineer it (mainly within the mdbtools project). So yes, somehow open sourcing the format could be useful, at least to develop better migration tools. But anyway, if the target platform is more modern than MS Access, e.g. like KEXI, there can’t be 1-to-1 feature mapping. It’s just because we do not expect to emulate all the WINAPI from 1990s to control UI elements or OS elements, and so on. I trust that’s not a no-go because, anyway even MS Access can’t migrate freely between all its versions.
Best regards!