Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

261–270 of 365 posts

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

#262
I've just been teaching some basics of DB to high school students; wanting to introduce the concepts of tables, forms, reports and queries, but without need to know too much technical stuff, administration etc. Access should have been perfect (I hadn't used it previously, but have programmed, used and administered a number of 'real' DB systems), but it just didn't make sense to me. I'm sure I could have learned it, but the workflow just wasn't obvious. As well as being ugly as hell. So I went looking for alternatives, and they're thin on the ground.

Went with Zoho Creator in the end, but even some of the concepts in that aren't intuitive (it treats forms and tables as the same thing).

Having done quite a few things with anvil.works in recent times as a 'modern Delphi' I'm left wondering when the 'modern Access' will arrive.

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

#263
Here's a little known fact - the Jet storage engine behind Access is alive and well. It's used by Active Directory and many other products at Microsoft. At my previous company, we built a distributed key-value store on top of it (much like using sqlite in a distributed manner).

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

#264
This reminds me of a job I had back in the mysts of time (...or more likely around 2003ish).

I was brought into a project where a seniour data scientist was working with MS Access but was runing out of room as it, at the time, had a database size limit of 1Gb on disk and our data set was about 2.5Gb in size.

We could have ported the whole thing to SQLite3, MySQL, PostgreSQL, MSSQL or even Oracle as we had site wide licences available.

Nope. MS Access was the favourite tool of this guy so in MS Access the data had to stay and I had to write code to juggle data between multiple simulataniously connect databases on a single machine.

This taught me a lot about how scienitst and accademics approach software engineering. My boss was both brilliant and really dum at the same time. He just wanted to get from A-to-B as "simply" as possible. He wasn't interested maintainablitly or assethics.

To this day the whole business still brings me out in a cold sweat of cognative disonance because on some level I know he may have had a point but on the other hand... I STILL have the flatspot that work gave me on my forehead from all the pointless wall banging involved.

I still beleive his work saved the company involved millions if not billions over years since it was presented. (...and I have never accepted another contract involving VBA or other Microsoft technologies since.)

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

#265

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?

Access is both a database engine and an UI and forms builder. You can easily design a database and make queries in the UI, and you can create custom forms to the extent that is doesn't look like a database anymore but just a custom desktop application. You can do that without any programming.

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

#267

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.

You are right, it was 2 then 3 then clipper for me, it has been a while. The compiling with clipper took around 45 minutes, we always went to the cafe to play some billiards in the waiting time.

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

#268
post #183
post #81

Earlier quoted context omitted.

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.

I partially fixed that by splitting the mdb into a front end and a back end where the back end was only tables (no UI, no queries) and launching the front end mdb from a simple command script that copied it to the users tmp directory first.

Then at least I could fix bugs in the UI and after a while that's where most of the bugs were.

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

#269

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…

NSBase[0] markets itself as Access replacement using sqlite as backend. It's built using Lazarus IDE and has lua scripting. It's free and works on Windows, Linux and Mac. I haven't taken it through the ropes to see how good it is. [0] http://www.nsbase.neuts.fr/en/

Seems like it's Windows and Linux only, at least according to the (outdated) web, and the download page.

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

#270
post #171

Earlier quoted context omitted.

I'd put that on the DBAs. Once a week they should have been pulling down backups and testing for problems. They'd have also discovered the problem with the backups themselves.

90+% of the good use cases for filemaker are at places with no DBA's, it's meant to be a database tool for non-technical people and small businesses. If you had DBA's they'd just want to lock it down and eliminate the remaining 10% anyway.

Still, someone should have been checking the backups on a regular basis, because anything can fail.
Post reply on HN