Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

171–180 of 365 posts

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

#171
post #144

Earlier quoted context omitted.

Unfortunately it silently fails. Years ago I worked for a company that claimed to have largest Filemaker Pro database in the southern hemisphere. One day there was some sort of disk issue and filemaker silently failed, then for months it kept pretending that everything was fine, it just wasn't writing to disk. This lasted until a power outage one day when the company discovered it had lost months of customer data, no…

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.

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

#172
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…

I wonder if sqlite could become this in the future.

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

#173
post #155

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.

It's because they were all Mac users -- in the early days it was an Apple (Claris) product.

Fun fact: it’s still owned by Apple

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

#174
post #106
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…

Agreed, I think it's because developers like to over engineer everything and the managers like to over engineer the processes. So many of these access excel solutions should be a days worth of work, simple perl cgi scripts with a minimalist UI deployed by rsync. Instead we have to use our super "productive" modern frameworks, split everything into a thousand files (god forbid you embed an sql query in the only place…

"So many of these access excel solutions should be a days worth of work"

I don't know why you think a lot of VBA would be replaced by a little perl. Of course, my perspective has a lot to do with the fact that it was essentially impossible to get a new perl module installed where I used to work.

But developers often don't appreciate the importance of presentation (and other) details in reports for managers. Your reference to "a minimalist UI" is telling.

Even though Access and Excel can be buggy, unstable, and annoying, it doesn't make much sense to use anything else if you are automating a report that was previously assembled by hand in Excel, and needs to match precisely.

And often IT types like to exercise power by gatekeeping - if you aren't doing "real" programming, you don't need a Turing complete solution, so Office ends up being the only option. I've been told that if I can select a list of columns from a dataset, and some filters, by pointing and clicking, that's all I, or my managers, need for reports.

Honestly, I think a lot of people find fulfillment in their work through being the person who can say "no" to people, particularly managers that are theoretically higher ranking. And also by expressing themselves through creative decisions when others fail to specify details. I think that using Office/Access/VBA may be correlated to rejecting the value system of most developers, rather than a technical judgment.

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

#175
post #5

As the author points out, Access fills an interesting niche where Excel isn't quite enough, but a SQL database and all the stuff that goes along with it is way too much. On top of that, it's completely local so you don't have to pay for licenses or worry about data policies. That niche is big enough to sustain Access pretty much indefinitely. I think the lesson here is that business users more often than not want som…

I'm not clear on why you are referring to Access as an alternative to a "SQL based application".

Access's SQL dialect is extremely annoying sometimes, but using SQL is a very significant (if not the most) reason for utilizing it rather than Excel.

I went around and around trying to find a way to query Excel "tables" with SQL or something similar, but eventually gave up. There is something called DAX, but it seems different just to be different, and nothing is orthogonal and logical - particularly external data is not on an equal footing with tables within your spreadsheet.

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

#176

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 !

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

#177
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…

I wonder if sqlite could become this in the future.

I wonder how much effort it would take to build a desktop application providing a similar user experience to Access, using SQLite.

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

#178

Interesting that the pie chart in the article omits Oracle - which was actually the #1 DB in the survey results. Not that I'm a fan of Oracle at all, but it makes me wonder.

saw that and it's very glaring. the author should be contacted.

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

#179

Earlier quoted context omitted.

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.

Even if MS feels they can't remove it - the fact they haven't made any significant improvements to it (even those to keep it usable on modern computers) means it will die a slow death and leave people stranded - the same way they did with VB6. For example, the SQL text editor in Access is so broken if you copy and paste tab characters they're displayed as zero-width and break text rendering (if you click+drag to crea…

I managed to corrupt my database and make all of the code irretrievable just by pasting a line that was too long, if I remember correctly. Luckily I was making daily backups.

I also ran into a bug where if you read a long calculated text field from a view/query through VBA, it corrupts everything after 255 characters, even though you can get the data otherwise through the interface or save it to a table. Googling suggested this problem had existed for 10-15 years.

Also, a lot of times your query will return neither a value or null, but "#error".

And I really hate the way it destroys all your formatting whenever you save a query. Every time I need to change something, I end up copying to a text editor and formatting by hand in order to find whatever error I just introduced.

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

#180

Earlier quoted context omitted.

I wonder if sqlite could become this in the future.

I wonder how much effort it would take to build a desktop application providing a similar user experience to Access, using SQLite.

Open/LibreOffice Base does have backends for MySQL and PostgreSQL already
Post reply on HN