Microsoft Access: Is it still relevant in 2022?

I see IT departments disliking MS Access applications often but consider this an illogical argument.

What they actually dislike is the fact that there is only a single developer and they don't know how the business logic works. So if that single developer goes no one knows how to fix or adjust the system. Its not really an argument against the technology.

This is not a problem with the method of deployment and would be just as much an issue if the solution was implemented with the latest greatest web technology and your given enterprise grade database engine. As Pat points out simply transferring the application to another platform isn't necessarily a solution.

Citizen Domain developers are super hard to replace irrespective of the technology they use.
They know the domain better than any new developer..
They are super motivated to make an optimal solution..
They develop over years not months..

MS Access just happens to be the way they have delivered their solutions. In fact MS Access is absolutely an optimum - microsoft is a stable company (it makes plenty of money) and Access has a huge user base. Visual Basic is possibly the most popular language in the world with infinite articles on every aspect of it built over decades and there are probably more available visual basic programmers than possibly any other language. Migrating from previous versions to the latest version of Access is nearly always painless..

What's not sustainable about that????

Some IT directors really need to get their logic sorted and stop being so short sighted. By all means force the backend into sql express / postgress / oracle (and appoint a dba to double down on solid backups) but if there's no outside vendor providing an alternate UI there is no legitimate reason to deny MS Access. Nice UI design is really really difficult and MS Access is amazing at UI design it still does the nicest master details forms that I have ever seen and its possible to do amazing colour work and conditional formatting in Access. Master details design for the web by comparison is really poor.

And as for difficulty in multiple developers on a single project -- that is a big problem with all platforms I've used.
 
Last edited:
In my experience, one of the biggest contributing factors to IT's well known dislike of Access is, ironically, it's very accessibility to "citizen" developers who have no idea what they are doing. We have all been there, or most of us. We see Access, we love Access, we build a garbage relational database application with Access. And then, if we are lucky, we get a chance to rebuild it correctly.

Too many times, though, IT gets called in to rescue the garbage application when it's already become mission critical. And they see the garbage application, not as a product of an inexperienced citizen developer, but as a "typical Access database" and rail against letting anyone use Access because it leads to that sort of thing.

In the one place where I didn't run into that, there was a long-term Access developer working as a consultant. He'd been there for many years as a consultant. His job was to take over those Access relational database applications and bring them up to standard. He had no desire to be hired full-time for some reason I never really got out of him. Nonetheless, that IT department didn't wash their hands of such databases; they turned them over to him to rescue.

Ironically, that was a quasi-government agency, where one normally expects layers of bureaucracy to prevent progress. Maybe that's why this developer preferred to remain a consultant, come to think of it.
 
In the one place where I didn't run into that, there was a long-term Access developer working as a consultant. He'd been there for many years as a consultant. His job was to take over those Access relational database applications and bring them up to standard. He had no desire to be hired full-time for some reason I never really got out of him. Nonetheless, that IT department didn't wash their hands of such databases; they turned them over to him to rescue.
That to me seems to be an optimal way of supporting citizen developers, improving security while taking advantage of MS Access's flexibility.
 
And as for difficulty in multiple developers on a single project -- that is a big problem with all platforms I've used.
Really? I spent 25 years developing using COBOL, CICS, IMS, with a variety of BE's and we always had multi-developer teams. We used source control for safety. The difference is that most programs were stand-alone or if they were sub-divided, the same programmer built all the pieces. In the situations where there was a super-app, we had a build master whose job it was to coordinate adding new/replacement subroutines to the big job and going through a test cycle.

It is hard to convince corporate America to include Access experts in IT who can oversee and advise the citizen developers. Not necessarily do the building. Just keep the amateurs on the straight and narrow. The reason the citizen developers exist is because IT is treated as a cost center rather than a profit center and so its resources are always limited by budget constraints. Unless a department can prove immediate and strong cost benefits, their requests for resources go into the queue and by the time they rise to the top, the business opportunity has usually passed. So they work with what they have - which is usually amateurs. Sometimes they hire consultants like me. I never know when I take on a project for a larger company if the app will become mission critical or just stay useful to day to day operations but more of an efficiency tool. The department could function without it but might need three more clerks due to the additional manual work. I always develop with good client/server practices so if the app has to be converted to SQL server, they can do it WITHOUT having to recreate the FE. I document this for the client and in the app so IT knows where to start if they don't call me.

My favorite clients are the small to medium sized companies. They have an accounting package but pretty much everything else is Access apps. Some integrated with each other. Some integrated with the general ledger app. There is usually a pretty big ROI on some very simple, small projects. For example, the accounting app has an Accounts Receivables section but they almost never provide good tools for a clerk or a small department to manage collecting past due amounts. The job is awful to begin with. Who wants to call people who don't want to talk to you and so are often downright rude? But, at least if you have an organized method of knowing who needs to be called and what
happened the last time you talked them, and then reports to show your successes to the boss, the job is doable. Depending on the complexity of what they want and how the interface with the AR section of the accounting package will work, I might spend 2 days to two weeks but probably not longer. And by the end of the first year, they've paid for the app and perhaps even made money so the ROI is huge. They have a happier clerk and they're bringing in money that would otherwise be hard to get. I love happy clients.

Also, because of the lack of IT support, I do everything possible to avoid general maintenance. One of my favorite gotchas is using Value lists in combos/listboxes or even tables if no user maintenance facility is provided. I've posted a mini-app many times over the years that can be imported and eliminate this problem entirely. I've always wondered how many people actually use the app or even the concept. It doesn't matter if you have three tables or a hundred. Having a simple way to always handle them that does not require the user to call ME to change the list is enough of a reason to use it in even the smallest apps. I don't need to be in the business of maintaining simple value lists and neither do you:)

 
Last edited:
Really? I spent 25 years developing using COBOL, CICS, IMS, with a variety of BE's and we always had multi-developer teams. We used source control for safety. The difference is that most programs were stand-alone or if they were sub-divided, the same programmer built all the pieces. In the situations where there was a super-app, we had a build master whose job it was to coordinate adding new/replacement subroutines to the big job and going through a test cycle.

Quite possibly my ignorance I have never done anything but development by myself and then really only in two platforms.
 

Users who are viewing this thread

Back
Top Bottom