Future of Access

[CJ_London]

The issue with large corporates is budget - I’ve provided many apps to service perhaps 3 or 4 employees who need a solution now, not two years down the line at a high cost. Wouldn’t be a problem if the large corporate systems provided the detail actually required, but the cost of modifying the system to do so is too high.

Large corporate systems are not designed to meet the strategic needs of their clients

 

[cedar]

Very interesting conversation.

A question that came up, how did the slant against Access take root in corporate IT departments, of course has several sides to it. One I think was mentioned, that IT folk aren't experienced with Access, never understand it's strengths, but do trip over it's weaknesses; and of course Access is not great for collaboarative development. But another reason is kind of paradoxical. There was a massive proliferation of small to medium sized Access projects in organizations precisely because they were so much easier and quicker to build, and typically didn't cost and arm and a leg.

Later edit: and the multiplicity of access dbs were unmanaged, often out of date, often had taps into data sources that with various permissions that could cause issues, and were often abandoned or hard to determine if they were still relevant or not. From that perspective, it's easy to see why many in IT would wish Access had never been introduced to their org.

 

[cedar]

They're not trained that way. They tend to go top down - "We're an Oracle shop." The end users that we often deal with do not seem to be who they work for; they work for whomever is higher up in IT. The higher ups in IT are even more remote from the end users.

Meanwhile the poor end users that actually get the work done for the org are being barraged by tasks and projects and often a sense that their data operations could be handled a lot better. Knowing that IT doesn't care that much, is overloaded, and slow, they often resorted to creating their own Access db, then when it gets too complex, they hire us; or they hire us from day one, often slipping in the engagement under the radar.

At least that's how it was in the 90s until maybe this decade. I'm not sure that this scenario is so common now. But it did result in hundreds of mystery databases scattered all over the place that no one who was supposed to be in charge of the data knew about. Yeah so they didn't like that.

Of course it could have made a lot of sense to recognize the reality (that end users were desperate enough to undertake stealth databases) and either helped out or facilitated or something. But probably the most common reaction was the urge to shut them down. Since they often couldn't (line of business dbs are useful!), it became a sore spot.

You'd think that a team (the company's inmates) could do better than that. But it's kind of like one of the other conundrums we see. IT folk tend to think they are way smarter than the end users (present company excluded), and often their bosses as well; but to many of the folks outside of IT, IT barely registers, and the help they provide seems more like finger in the dike than making things a lot better. I am sure that many/most/all of the people here have high regard for end users, but not everyone in IT or management does. Maybe that too is a part of why Access can be looked down on - anyone with interest can build something useful. Doesn't sound very elite!

 

[cedar]

BlueSpruce that's a good question. I would guess that it's because probably the majority of business users natively use Excel for tasks, they have to to crunch numbers, just like they have to use Word for documents. But Access is not in the same category - with it you can create applications that rival turnkey solutions. IT might be called in to manage someone's Excel files when they leave for another company, but just as likely some peer of the now gone employee takes over the files. You'd think that an employee would use or port to Access because it's more capable than Excel. By the same token, because Access is more complex, it'd be harder to wade in to if you had to take it over, esp if you're an IT person that has mild or no exposure to Access. Then factor in what Uncle Gizmo just said, that most home grown applications like these are a big mess inside. Not a lot of fun for IT.

The greatest mystery of all is why Microsoft, with all of it's resources, has not been able to come up with something that is just a great as Access is, that was built from the ground up to be acceptable to IT, hopefully anticipating a migration path between Access and that product. The potential for such a product would be colossal. Maybe Lightswitch could have been that, but they let it go so easily.

 

[cedar]

But .net is massively more complex than Access. Webforms tried to be like vb6/Access, not sure if those are considered bound controls. But webforms had a lot of negtives and is a backwatered framework at this point.

A corporate worker could dig in to a book or two and write a line of business application (which probably needed to be refactored by someone that was more experienced). That didn't happen much with .net - too steep of a climb.

 

[Steve R.]

The greatest mystery of all is why Microsoft, with all of it's resources, has not been able to come up with something that is just a great as Access is, that was built from the ground up to be acceptable to IT, hopefully anticipating a migration path between Access and that product. The potential for such a product would be colossal. Maybe Lightswitch could have been that, but they let it go so easily.

Corporations evolve. They start off as aggressive entrepreneurial innovative companies, but as time progresses the innovators leave and the corporations become ruled by lawyers and accountants. Look at Boeing's space program versus Musk's space program.

Because my memory is imperfect, I leaned on ChatGPT to provide the following answer:

That idea is most commonly associated with Murray Rothbard, an American economist and political theorist of the Austrian School and a major figure in libertarian thought.

Rothbard argued that large corporations—especially those deeply connected to regulation, subsidies, or government contracts—effectively become extensions of the state. In his view, the line between big business and government is often blurred, forming what he called a “corporate state” or “state capitalism.” He suggested that these corporations derive their power not from free markets but from their relationship with government, making them functionally indistinguishable from it.

For Microsoft, MS Access is probably nothing more than a "cash cow". Something that still provides revenue, but is no longer relevant to their corporate objectives. Consequently they don't want to invest in it.

 

[The_Doc_Man]

The biggest problem with Access is not actually scalability, that can easily be handled by SQL Server or other RDBMS but is its clumsiness as a multi-developer platform to support parallel development by multiple developers at one time because it uses a single container for all objects.

An astute observation, Pat. Not unique, not the first time it has been said on the forum, but absolutely on point. I had that issue ten years ago with my big Navy security status tracker app.

 

[Isaac]

And the same is true for some of the first iterations of programming like cobal... I understand many bank applications are built on incredibly antiquated software..,..

They are! I've worked for 2 major fortune 500 banks and they have many old parts of them that desperately need to be reimagined.
Same is true (even more so maybe) for gov entities. Worked for a state Taxing authority and they had 2 systems where "one guy" in the whole organization knew how to edit or maintain it. Boy, did he stand up straight when he walked. You couldn't tell him anything LOL because upon his whim the Arizona Dept of Revenue exists! Really incredibly awful risky stuff, but they do it

 

[GPGeorge]

My goodness. We've been begging for better ODBC connection handling for 10 years now.

 

[RonPaii]

The biggest problem with Access is not actually scalability, that can easily be handled by SQL Server or other RDBMS but is its clumsiness as a multi-developer platform to support parallel development by multiple developers at one time because it uses a single container for all objects.

Going 3rd party with source control solves the multiple developers problem.

I have been using joyfullservice (Access add-in) combined with Tortoise Git (Window Add-in) and Git Hub. I can export changes form the FE then commit to Git Hub. Changes can be merged in Git Hub and then downloaded and with the add-in to build a new FE from that source.

All the files created by the addin are text with 2 file for each form/report. One for the form and a 2nd for the VBA code behind form.

 

[RonPaii]

Source control is only part of the problem. I don't know how this tool works, it's been years since I last tried a source control addin. At that time, the process was abysmally slow but more important was that you had to remember to "check out" BEFORE you started modifying an object. Modifying an object should have automatically initiated the "check out". If you don't "check out", your changes didn't get logged. I would hope that newer versions are better.

The real issue is that if Bob makes a bad change and checks it back in, I may not be able to work on my piece if Bob's change broke something I needed.

Working as a team requires a build manager and the build manager should be the only person who can check objects in and he has to thoroughly check them as well as all other objects before the new changes can be incorporated into the current build.

I've tried a few times to have other developers work on isolated objects and that can work but again, you need one person who incorporates changes made by any team member. That meant me in all the times I tried this method since who can afford an extra developer who just handle's the build?

Using Git Hub, Bob is working on a fork as are you, there is no checkout. The changes are merged back into the main after testing and can always be rolled back.

I am working with a large FE, the add-in exported the original in a matter of minutes, changes take seconds. After working with source control I have been refactoring the code in a more vertical orientation to work better with side by side comparison.

 

[sonic8]

Microsoft announced the removal of Salesforce ODBC driver from Access, effective October 2025:
[...]
Which are the next ODBC's Microsoft will remove?

I don't think there are any other ODBC drivers built into Microsoft Access.
Does this answer your question?

 

[sonic8]

I don't know how this tool works, it's been years since I last tried a source control addin. At that time, the process was abysmally slow but more important was that you had to remember to "check out" BEFORE you started modifying an object.

There was such an issue with Microsoft's own SCC plug-in for Access. And, I agree, this was a major nuisance.
AFAIK, all current source code control add-ins do not require to explicitly check out before making changes. For Git based version control, the Check Out step is generally no more part of the SCC process.

The real issue is that if Bob makes a bad change and checks it back in, I may not be able to work on my piece if Bob's change broke something I needed.

This is neither specific to Access nor to source code control. If someone breaks code in your project, there will be a problem.
Source code control just makes it easier to add or modify code, be it good or bad, in a shared project.

Working as a team requires a build manager and the build manager should be the only person who can check objects in and he has to thoroughly check them as well as all other objects before the new changes can be incorporated into the current build.

I strongly disagree with having a human person (=bottleneck) as gatekeeper to validate all check-ins to a system. This will slow down the development process to a crawl.

With Git any developer would usually check in into a local copy of the repository first, and only later will these changes be incorporated into the common shared source code in a "central" repository. - This would be were you could insert the human gatekeeper into the process, without creating too much of a drag. Nonetheless, I still discourage that.

Automated testing is the key to reduce the risk of someone checking in bad code into a project and breaking it for everybody else.
For larger projects we have an automated process in place, that after each check-in will ....
- create the project's Access file from source,
- (try to) compile the code,
- run our code quality checks (powered by MZ-Tools),
- run all Unit/Integrations tests for the project.
If any of these fail, the automation process will alert the offending developer and optionally other team members of the problem.

As this happens after the check-in operation in our process, it does not prevent bad code from being checked into the repository. But the alert to the relevant developers allows for a quick fix of the problem.
One could also change the process to automatically roll back such a bad check-in and thus prevent bad code from entering the repository.

 

[sonic8]

None of the ODBC drivers are built into Access.

Did you actually the read the announcement you linked to?
The Salesforce ODBC drives *is* built into Access and will now be removed. That is what the announcement was about.

 

[RonPaii]

This is more of a problem with Access due to the single container. If the bad code is in the container, I may not be able to work on my part of the project without finding and disabling the bad code.

With an add-on like joyfullservice which exports each Access object to a text file, the single container is not an issue. A new ACCDB FE is generated with each build much like you would do with a .NET project. The process is develop in your copy of the FE, export the changes to your repository then push to the central repository. Other developer's changes are pulled from the central repository allowing you to build a new version the the FE. The ACCDB FE becomes a deliverable just like a DLL or EXE from .NET or Java or Python.

 

[gemma-the-husky]

I think the difficult thing with web software is enforcing the time-sequential nature of things. The very way web sites work makes ensuring the logic flow of a commercial (database) application is awkward. Not sure what the technical terms are.

 

[RonPaii]

It is an issue if the person who installs the new code into the .accdb doesn't do the proper regression testing. I understand how the source code manager works. I use the export to/import from text feature for my own personal backups.

All development environments have the same problem if you release without proper testing. You can get daily example on the Daily WTF site.

Moving to source control made it much easer to track changes and undo mistakes. I need to get much better at Git but the basic feature I use are very powerful.

By the way joyfullservice use the add-on and is available on Git Hub, you can fork it, build your own copy and modify your copy. I did that when I saw something, after making my edits and testing, I posted back and the changes were added to the main branch.

 

[RonPaii]

I agree but usually the bad module doesn't affect other parts of the application as it can with Access.

I agree but usually the bad module doesn't affect other parts of the application as it can with Access.

Having source control is excellent, especially when working with a team. Since I generally work alone, I am religious about backups and I use export to text to prevent backing up corrupted versions of the database.

I don't understand why you are treating errors in an Access module any different then any other environment. If I make a breaking change in a c# class, any other class importing and using the class will have a problem. The problem with Access and VBA is the limited IDE and the resulting difficulty of using modern development process. I can shoot my self in the foot just as easily with C# and VBA.

 

[RonPaii]

It seems that I cannot explain it so you understand the problem.

Maybe were are talking past each other but once I started using joyfullservice for export and build and Git for source control, I started looking at the ACCDB FE more like a DLL. I can fork the source in GET to try a something new. If a change to the production FE is need before the fork is done, I can restore that version, make the change, test, release the go back to the fork and import those change or when the fork is done I can merge with the main to include changes made to the main. The ACCDB or ACCDE is just a release, GIT has the source with each object in it own file(s). BTW I also generally work alone.

 

[RonPaii]

I thought Visual Studio was more versatile than Access' IDE? Even if vba code modules were stored externally in Windows files, you still have to compile, link and load the object files, and runtime errors can still happen even though the modules compiled.

I not using Visual Studio for VBA. The programing is done in the ACCDB, the add-on is used to export changes and if I need to import from GET or roll back, builds that source into a new ACCDB which is then compiled like normal. The joyfullservice add-on is not source control, GET handles that. It is the interface and builder.