Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

Post reply on HN
Print view View original

191–200 of 365 posts

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

#191

Post by insaneirish »

SigmundA wrote: post #30

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…

> I still think there is a killing to made on a modern day Access "Done Right". DB, Gui framework and printable report generator all in one sharing the same language front to back, top to bottom.

I don't know what the actual market [that will pay money] is for it, but I can certainly say I've never seen anything quite like it.

In high school, I worked as a sysadmin/misc. programmer for a company whose whole business was software built on top of Access. I was the weird Linux person who ended up having to do a lot of stuff in Access (97).

It had its issues. It was not perfect. But the simplicity with which you could bind a visual tool and query designer to an ODBC/SQL backend--I think--goes unmatched 'til this day.

There are many things I cram in a spreadsheet these days that would be way more flexible if they were instead built on a quick and dirty Access DB.

If there are equivalent tools out there, please, let me know.

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

#192

Post by flukus »

perl4ever wrote: post #174
flukus wrote: post #106

Earlier quoted context omitted.

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 refe…

> 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.

We're talking access here, at best it's ugly and at worst you've got a gaudy background image(1) and a color scheme that would give the disability compliance officer a stroke. Throwing in bootstrap or a more minimal css framework is a huge step up in terms of presentation.

> 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.

I'm thinking of scenarios a bit more complex than that. Access apps generally have a few data input screens, multiple users, etc. Not complicated but not as simple as reports.

I'll admit that I do run away from anything to do with reports, but usually that's because they've installed some "easy to use, no developers required" reporting system that the non-developers can't use and makes life 10 times harder for the developers. If I can just write sql to shove data into an html table or excel template (where we can have the best of both worlds) I'm more than happy too.

1. I actually think of some of these old access programs when I look at windows new built in mail app, who the hell adds a background image?

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

#193

Post by _AzMoo »

jdfellow wrote: post #177
WrtCdEvrydy wrote: post #172

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.

Why would you do that though? The underlying database technology is not really one of the problems access has.

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

#194

Post by dvdhsu »

SigmundA wrote: post #30

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…

Hi! I'm working on a project called Retool (https://retool.com), and it's basically Access, in the cloud. We connect to any sort of cloud database / API, and let you build UIs quickly. It's good for building forms that write back to APIs, tables that read data from databases, etc.

I'd really appreciate HN's feedback on this -- if anybody has thoughts -- I'd love to hear them! I'm also david@ if you'd rather email me anything. Thanks!

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

#195

Post by wil421 »

akdor1154 wrote: post #168
linza wrote: post #138

Earlier quoted context omitted.

I was curious about ServiceNow and googled it and was excited as they offer demos. But they require registration and a lot of information about myself, so i stopped. Is it not meant for small businesses perhaps?

As a developer who is forced to use a service now interface for interacting with any other part of my organisation it's fucking awful in terms of user interface and friction. Unsure if that is because of our workplace setup or if it's intrinsic to the platform.

SerivceNow’s partners are godawful at implementation. Thanks to them I have decent job security unraveling the dog shit they left.

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

#196

Post by yyx »

krilly wrote: post #180
jdfellow wrote: post #177

Earlier quoted context omitted.

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

I wish it was this easy to connect sqlite

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

#197

Post by Ididntdothis »

james_s_tayler wrote: post #78
SigmundA wrote: post #30

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…

Isn't Airtable considered like modern day Access?

I have played a little with it but I found Access much more powerful and easier to use than Airtable.

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

#198

Post by Ididntdothis »

codeulike wrote: post #85
phs318u wrote: 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…

Yeah exactly. Working in an IT Dept when someone said "ah they've built a spreadsheet to do it, but now they want us to add that functionality to the main DB" we'd all roll our eyes because it was another lashed-together thing that we would have to unpick and re-implement. But the fact is, if they'd come straight to us and asked us to do it instead of doing it in Excel first, they would have had nothing, for years an…

“But the fact is, if they'd come straight to us and asked us to do it instead of doing it in Excel first, they would have had nothing, for years and years.”

Very true. As soon as us professionals take over the dev speed drops drastically and costs go up.

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

#199

Post by orionblastar »

SigmundA wrote: post #48
jjkaczor wrote: post #42

Earlier quoted context omitted.

>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 doubled clicked the MDB You could be describing myself. However... I beg to differ on it's scalability... There were 'issues' with the 2.0 Jet engine when accessing MDB files on network shares that would often result in 'missing data'. Lots of fun. (Lots of work up-sizing to actual SQL b…

Oh I didn't say it was without problems, but it did mostly work , mostly... Once I started learning SQL server and VB5 for real client server apps I never looked back, but then you had to go find a reporting engine too.

Crystal Reports worked great for me. Even had ActiveX and ASP versions. Only problem was Seagate Software was in Canada and CR was quite buggy. So I got docked in my paycheck for calling Canada. It is SAS now I think.

Lotus Approach also did the same as Access.

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

#200

Post by euske »

The three characteristics in OP reminds me of PHP. 1) It was aimed at people who aren't that much of a programmer, 2) it made them feel empowered, and 3) it just works in a relatively simple setup.

(I'm posting only because I thought that someone must have mentioned this for sure, but couldn't find one.)

Post reply on HN