Access let you build visual apps, usually data-entry workflows, around its internal SQL database. You could build small apps with it using Visual Basic and a visual UI editor. Plus, all your work ships as a single file, provided the user also has Access installed. In many ways, it was like Apple’s Hypercard, but also way easier to write than webpages with the same capability. Oh, and you don’t need a server anywhere to make it work; it’s 100% local. It was also the next logical step to take after the most complex things you can do in Excel.
That said, it was crippled from the start - still very useful, but not for heavyweight stuff. It’s limited to a fixed number of UI, pages, database rows, etc, so it wouldn’t compete with more expensive MS solutions (this thing came with Office). I don’t think it got a lot of love because of that, but I personally used it to solve some real problems in the workplace, without need of any (official) developer resources.
In the present day, it would actually compete with a lot of simple business cases that are served in the cloud at some cost.
Honestly Microsoft could’ve had a killer product with Access if they made an easier pipeline from Excel -> Access -> Win32 application/webpage with an SQL backend. Like there is some of that pipeline present, but if Microsoft actually followed that vision, created easy wizards for each step that your average office drone can complete and marketed the shit out of it, they could completely own business processes instead of a cottage industry of spreadsheets turned SAAS apps for every niche usecase that could’ve been handled by a common database frontend.
On the other hand, now we have a super easy jumping point for anyone in a large business who can program a little to spin up a new startup. Find a business process that’s currently a spreadsheet/on paper, write a database frontend to easily handle that then sell your solution to businesses looking to remove load bearing paperwork and spreadsheets
Exactly. Access was a dirt-cheap rapid application design (RAD) tool in disguise, and very easily could have been shaped into a smooth on-ramp to ASP, ASPX, IIS, and SqlServer solutions. In short: a hypothetical “Access.NET” would have been really something.
On the other hand, now we have a super easy jumping point for anyone in a large business who can program a little to spin up a new startup. Find a business process that’s currently a spreadsheet/on paper, write a database frontend to easily handle that then sell your solution to businesses looking to remove load bearing paperwork and spreadsheets
You just described most of my career, and how a lot of contracting shops get their start. Managers need reports, and someone has to program them. I’ve lost count of how many times I’ve replaced Excel with custom software; a faster way to do this is usually welcome. That said, the cloud “Data” space is doing a lot right now to reduce this kind of task to Jupyter notebooks and some other proprietary solutions.
What does it do again?
It’s what many should have used instead of doing everything in gigantic macro filled Excel file.
Access let you build visual apps, usually data-entry workflows, around its internal SQL database. You could build small apps with it using Visual Basic and a visual UI editor. Plus, all your work ships as a single file, provided the user also has Access installed. In many ways, it was like Apple’s Hypercard, but also way easier to write than webpages with the same capability. Oh, and you don’t need a server anywhere to make it work; it’s 100% local. It was also the next logical step to take after the most complex things you can do in Excel.
That said, it was crippled from the start - still very useful, but not for heavyweight stuff. It’s limited to a fixed number of UI, pages, database rows, etc, so it wouldn’t compete with more expensive MS solutions (this thing came with Office). I don’t think it got a lot of love because of that, but I personally used it to solve some real problems in the workplace, without need of any (official) developer resources.
In the present day, it would actually compete with a lot of simple business cases that are served in the cloud at some cost.
Honestly Microsoft could’ve had a killer product with Access if they made an easier pipeline from Excel -> Access -> Win32 application/webpage with an SQL backend. Like there is some of that pipeline present, but if Microsoft actually followed that vision, created easy wizards for each step that your average office drone can complete and marketed the shit out of it, they could completely own business processes instead of a cottage industry of spreadsheets turned SAAS apps for every niche usecase that could’ve been handled by a common database frontend.
On the other hand, now we have a super easy jumping point for anyone in a large business who can program a little to spin up a new startup. Find a business process that’s currently a spreadsheet/on paper, write a database frontend to easily handle that then sell your solution to businesses looking to remove load bearing paperwork and spreadsheets
Exactly. Access was a dirt-cheap rapid application design (RAD) tool in disguise, and very easily could have been shaped into a smooth on-ramp to ASP, ASPX, IIS, and SqlServer solutions. In short: a hypothetical “Access.NET” would have been really something.
You just described most of my career, and how a lot of contracting shops get their start. Managers need reports, and someone has to program them. I’ve lost count of how many times I’ve replaced Excel with custom software; a faster way to do this is usually welcome. That said, the cloud “Data” space is doing a lot right now to reduce this kind of task to Jupyter notebooks and some other proprietary solutions.
No one truly knows, but there’s always that one guy in the office using it for god awful things it was never meant to do…