Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

31–40 of 365 posts

Re: Microsoft Access: The Database Software That Won't Die

#31

This is the question I always wanted to ask, I almost wrote an Ask HN... Who use Microsoft Access in 2019?! An obvious case is creating a glorified/enhanced Excel for some specific office tasks, another case is that some applications use ".mdb" backend. But that's all? edit: What I'm interested in is cases of using Access for something other than a specific Excel-like office task - it seems Access is still used for s…

An acquaintance of mine is an accountant. He uses it when his spreadsheets get too big/busy/complex. He's not "technical", but he is quite intelligent and is very familiar with Excel, has even written a few VB macros here and there. It's perfect for him. I assume the thousands of people just like him are the answer to your question.

Re: Microsoft Access: The Database Software That Won't Die

#32

Earlier quoted context omitted.

I started to write with Dbase 1 and 2

There was no "dbase 1", it started as "dbase 2" because Ashton Tate didn't want the product to sound premature.

To be fair, they probably mean dBase II and dBase III. Although they could mean Vulcan and dBase II, which is less likely. I started my "database" programming career on dBase II in the early 80's and never bumped into Vulcan.

Re: Microsoft Access: The Database Software That Won't Die

#33

This is the question I always wanted to ask, I almost wrote an Ask HN... Who use Microsoft Access in 2019?! An obvious case is creating a glorified/enhanced Excel for some specific office tasks, another case is that some applications use ".mdb" backend. But that's all? edit: What I'm interested in is cases of using Access for something other than a specific Excel-like office task - it seems Access is still used for s…

An acquaintance of mine is an accountant. He uses it when his spreadsheets get too big/busy/complex. He's not "technical", but he is quite intelligent and is very familiar with Excel, has even written a few VB macros here and there. It's perfect for him. I assume the thousands of people just like him are the answer to your question.

Thanks for the story. I can imagine that, as I said

> creating a glorified Excel for some specific office tasks

What I'm interested in is cases of using Access for something other than a specific office task - it seems Access is still used for some serious business in many businesses (pun not intended).

Re: Microsoft Access: The Database Software That Won't Die

#34

Is there a modern and/or open alternative to this? E.g a SQLite + electron or local web client thing where you could build a simple inventory or similar but you should also be able to scale it to client server when the need occurs 10 years down. Note that any number of cloud startups don’t count as an alternative to access. When these things start it’s as an excel sheet with data that no one will go through the enter…

I think that Open/Libre-Office have options for this. You can also use Access as a front end for another db (odbc) backend pretty easily. I'd probably do a web app myself, but that's just me. I know a lot of people that cut their programming teeth on Access apps, including distributed ones.

OO/LO "Base" is a pile crap in my opinion.

People often develop smallish CRUD apps in MS-Access in two weeks or less. It's up and going without fuss and muss and without fiddling with servers, containers, DBA's, etc.

You have to admire its nimbleness.

Yes, the database "crashes" fairly often, but it's easy to make frequent round-robin-style file-based backups using Windows Scheduler and DOS scripts.

Most databases cannot be properly backed up with file-based techniques because of syncing of internal pointers. But MS-Access's separate "lock-file" based technique somehow facilitates file-based backups.

Such MS-Access apps are far from perfect, but if you factor in everything, they seem to be a net benefit.

I'd probably do a web app myself

If follow-on maintainers don't know the web framework used, it can be hard to maintain. Web apps are rarely nimble to do without an involved framework on which the developer is familiar with. MS-Access avoids that problem with ubiquity and a light drag-and-drop learning curve. (It did get harder to learn when they went from coordinate-based to an HTML-esque flow engine around 2006.)

Let's face it, desktop GUI IDE's are usually much easier to learn than web stuff. You don't have to deal with the web's lack of state, and CSS/DOM/JS headaches/bugs/inconsistencies.

Re: Microsoft Access: The Database Software That Won't Die

#35
post #26
post #7

The reason that both Access and Excel use is so prevalent in corporate “shadow IT” land is because there are many parts of the business that have problems for which only a negative or marginal business-case can be made for IT to solve it (given the “get out of bed” costs of most IT departments). It’s a barrier-to-entry problem. Excel and Access are cheap enough and fly under the corporate IT radar (no involvement nee…

I think Developers also underestimate IT Setup Costs for a DB since its so easy to do it locally. Setting up a simple RDBMS like MySql or Postgres and skinning with with a basic, out of the box UI is an afternoon of work if you need to look up commands, or minutes if you have done it recently. But setting up something for a Team immediately opens questions like Access Rights (Can we limit this just to the team, or ev…

I've worked in multiple organizations that run small Access apps here and there and for us the main cost is just sitting down and doing it.

My last job was at an HR company and things were historically done through Access and spreadsheets, until an IT guy came along and started writing C# web apps, rose in prominence and now runs a small internal software team. I worked for that guy.

It's not terribly politically difficult to convert existing applications, but it's mind numbing work and it's bottom priority. There's not a huge need to change something that already works, and the only reason you do it is you know it can't stay like that forever.

Re: Microsoft Access: The Database Software That Won't Die

#37
post #14

I will admit a love/hate for Access. Namely, from years of teaching Microsoft Office as Intro to Computing. Access was always the section that was hard to convince students they'd ever need and worse yet outright made the class logistically harder for Mac users. I will say, however, Access has SOME benefit to Information Systems education, especially in a general IS class. These students are marketing, accounting, et…

I wonder how many people became actual programmers due to Access. I feel like MS can't remove it just like you can't remove the second rung of a ladder.

Re: Microsoft Access: The Database Software That Won't Die

#38

The amount of people I work with who use Access who do not understand even the very basics of computing is shocking. And half my help tickets now are fixing Access files from multiple users trying to use them at once...

The point though is that this isn't Access's fault. If Access didn't exist, those people wouldn't be magically replaced by expert DBAs who knew how to set up a perfect solution in Postgres or whatever. They'd be the same people, except hacking together some Rube Goldberg machine in Excel or Google Spreadsheets, with even worse functionality and none of the AD controls that Access at least gives you.

Re: Microsoft Access: The Database Software That Won't Die

#40

I have a special place in my heart for Access, its where I first started making money writing software and learned SQL and VB. Its where I really felt like I was making something that solved real world problems for people, quickly at that. It was actually amazing how far it could scale, you could put a shared MDB file out on a Novell network share and have 30 concurrent users with no server app at all, users just dou…

My first real paying gig was Access 97 (I'm old). They actually taught it at my university at the time in the MIS/CIS path. I built a credentialing system for a small HMO. I was able to get it to support over 100 people, including report load. I split out the database from the front end (forms/reports) and put the database files on an NT4 share. When we grew and it started to buckle under load, I created an additional read-only share and replicated the read-write database to the read-only database every so often. This allowed me to split the users' load between those that needed read/write and those that needed read only.

Talk about a rapid design tool of both forms and reports (and schema), Access was tough to beat. I think Corel/WordPerfect had a similar concept as well.

Good times.

Post reply on HN