Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

181–190 of 365 posts

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

#182

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…

Why would anyone use Access in 2019 when they can use SQLite instead? Is it because Access has a graphical interface?

This is like saying why would anyone use a Toyota RAV4 when they can get a 400+ hp LS3 crate engine from Chevy. Is it because of the quality of the dashboard plastics?

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

#183
post #81

A number of years ago I was in the Navy and worked in an electronics shop on an aircraft carrier. We were responsible for calibrating and repairing all the test and measurement equipment for the entire ship as well as the squadrons that we carried with us. Easily over 10k individual pieces of equipment, each of which had to be calibrated on a specific schedule. Most of this data was managed centrally, and we sent/rec…

Huh, similar story here. The nuclear department on my carrier needed to produce this monthly report for training hours that would take them a ton of manual effort. There was no budget at all for any kind of automation but Access was on every machine. I know what I'm doing with databases. I never want to use Access if I don't have to. But it has the enviable property of "no server administration required" which meant…

Fun getting everyone to close their MSAccess processes so you can do some changes to the MDB.

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

#184
post #58

Earlier quoted context omitted.

I don't disagree, but isn't it a sign of much deeper issues if this "Shadow IT" land exists at your company in the first place? Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Are they under-staffed? Neck-deep in spaghetti code? Lacking business knowledge and the opportunity to acquire it? Bottle-necked by a lack of business analysts or testers? I he…

Because developing software is at least an order of magnitude easier and faster when the developer is the user?

This is so true.

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

#185

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…

[deleted]

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

#186

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…

Not that I've seen. You figure with file base databases it wouldn't be hard to put something together (sqlite?)

Libre office has "base" but its just a front end. My boss uses access, she like the query builder. I've got my mysql instance and some front end tools that do the same, but I'm a developer.

Filemaker is another of these applications, but not open source. The thing these stand alone apps have is direct printer access for printing forms and labels. It makes it hard to get off.

(Our get off filemaker solution is to download the data from our website and use a stand alone print app to print the labels. One extra step, but its not completely ideal.)

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

#187

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…

Access is highly underrated. I was able to build a CRUD app with 20 concurrent users in a month just using a shared directory to host the backend database. It would have taken a team of engineers 6 months to do the same properly developing a Java web app with Oracle database. Access does have such easy WYSIWYG reporting tools that I still miss.

I was never more productive than using Access. Once wrote a full budgeting, cost estimating tool. Supposedly impossible. (Access' VBA had an 'eval' function.)

We lost something in the switch from "workgroup" (dBase thru Paradox) to client/server.

Spoiler: ODBC broke the tight coupling of code and persistence. Spawning monstrous hacks like ORMs and ActiveRecord. What Ted Neward famously called The Vietnam of Computer Science.

It took me a very long time to figure out what went wrong. Even longer to fix it.

Cliff hanger, I know. Someday I'll post polish and publish that fix. Using my real name.

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

#188
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 believe Bill Gates' assertion that "90% of software hasn't been written" is more true every day.

There are so many "workgroup" size (1-10 users) apps that simply don't get written with today's tool stack.

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

#189

Earlier quoted context omitted.

FileMaker, in my experience, attracts a certain smug developer who simply cannot believe that there are more industrial-strength database systems and that FileMaker can't solve every possible problem in the world. Access devs, at least, don't seem to have that particular quirk.

I wouldn't rag on it or Access too much because it serves/d a purpose: app and data design for less technical users who are busy doing a million other things. I supported several dozen FMP apps at Stanford Student Housing (R&DE) as it was easy for analysts to make something quickly and worked at the scale needed. Later, they used proper databases, reporting, and app-ish tools. FMP ran on a half dozen early Xserves wh…

I'm not talking-down either one. They're both great tools for their purpose. I've used Access a ton.

I guess I'm talking about a cultural difference. It's been my experience that Access devs know when a problem is mismatched for Access (and move to storing data in SQL Server, etc). FileMaker devs seem to press on even when it's clear that the platform isn't capable of supporting their needs.

As one anecdote (of several): I support an instance of a FileMaker application w/ several 500MB+ "FMP" files, each of which take _hours_ to "integrity check" when the "FileMaker Server" process crashes unexpectedly. We talked to the dev about putting at least some of the data into an RDBMS (MSSQL, Postgres, etc) and they scoffed at the idea. It simply didn't occur to their mind that the platform might not be a good fit for the purpose.

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

#190

A number of years ago I was in the Navy and worked in an electronics shop on an aircraft carrier. We were responsible for calibrating and repairing all the test and measurement equipment for the entire ship as well as the squadrons that we carried with us. Easily over 10k individual pieces of equipment, each of which had to be calibrated on a specific schedule. Most of this data was managed centrally, and we sent/rec…

In the AF we called it PMEL. My anecdote is getting a 9 track tape of all of the test equipment part numbers and calibration intervals (TO-1-1-100 , maybe?). transfer the tape to a disk file, sort it and use binary search. a couple of years before ms access, but turbo pascal was king !

Man haven't heard "PMEL" in years - Precision Measurement Equipment Laboratory if I remember correctly?
Post reply on HN