Live data from Hacker News

Microsoft Access: The Database Software That Won't Die

medium.com

321–330 of 365 posts

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

#321
Years ago an acquaintance was running a MICROS POS for his restaurant, and lamented the heavy tax burden the local government levied on him.

I was able to create an external software application (we called it "CookBooks") that would selectively skim off cash transactions (ignoring credit card transactions) from the Access database.

This allowed him to reduce his tax liability and pocket a substantial amount of cash on a nightly basis.

This was in 2002 and I recall that it took no time at all to gain update access to the underlying proprietary Access database powering the MICROS system.

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

#322
post #194

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

Half of the point of Access is that it's not in the cloud; it's a locally installed app that doesn't even require network access or admin rights.

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

#323
post #251

Earlier quoted context omitted.

You can do the same in Java. Netbeans with Swing UI designer and database bean components.

That would mean using a server for the database, which means lots of meetings getting buy in only for it to be prioritized to get done 9 months later. You also have to deal with DBAs who like to say no and permissions every time you have to make a change. Even if you broke down all the bureaucratic barriers, Access is still quicker to make a simple to make a simple CRUD UI than Java swing. Sometimes worse is better.…

The database could run local.

I have experience with both and the NetBeans UI designer is hardly much different.

Now if we compare languages, Basic dialects win hands down for such scenarios.

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

#324
post #279

Earlier quoted context omitted.

If you look at how things have progressed from the GUI desktop->web->mobile you get a reasonably good flavor of the trade-offs that have been, and continue to be, made. Compare the richest, most powerful spreadsheet application you can find on the desktop to the same on the web to the same on mobile... there you go ;-) (and it isn't just the relative maturity of the platforms: once one player dominates a platform, th…

> [1] It's 'good enough' for the majority of use cases. Some would argue that the lost features were cruft anyway. Which is fine unless you needed that cruft... I don't like that "good enough" argument, because it misses the fact that features shape use patterns. Features are enablers. To give a random example: I once visited my wife's office, and was given a task I could help them with while waiting. It was a task t…

Agreed and you give a perfect example of the type of feature that is often the first to go.

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

#325

Earlier quoted context omitted.

I tried doing this once with Go, hoping for a static binary, but SQLite library requires glibc. There’s a huge need for a sql-compatible sqite-like database for this purpose in Go.

So, link in glibc statically? I may be wrong, but sqlite is used a lot on Android which uses bionic, not glibc right? So it seems like there should be hope of switching to another libc if you need.

With sqlite3 package and Go this doesn’t look possible, or at least not easy.

https://github.com/mattn/go-sqlite3/issues/212#issuecomment-...

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

#326

Earlier quoted context omitted.

Salesforce, the core database/CRUD bit of it if you ignore all the stuff they've purchased and tacked-on in the last few years, is essentially 'Access in the cloud', in terms of the sorts of things you can do and the ease with which you can do it, and how far you can stretch it before it starts to get cumbersome. And yes, they are making a killing. edit: And if that sounds easy, imagine how you would go about upgradi…

While I agree fundamentally with your premise, I would have to point out that MS Access was always software-as-a-service for developers. Ultimately, while it was accessible, the idea was to give powerful tools to developers to refine an interface/toolset for users. SalesForce, on the other hand, seems to be more a platform-as-a-service targeted at the user with aspects such as SOQL instead feeling like a bolt-on to g…

[deleted]

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

#327
post #320

Earlier quoted context omitted.

I don’t use Windows, so Access isn’t part of the MS Office equation for me (on a Mac). However, I’d very much like to have a simple database that I could use instead of tracking certain things in Excel. So... I can completely understand why someone would be interested in making a more universal solution for this very common problem.

The Mac equivalent (for decades now) is FileMaker. Which, now that I look at it for the first time in a long while, seems to run on Windows and the web as well. [1] [1] https://www.filemaker.com/products/filemaker-pro-advanced/

Yeah, I’m aware of FileMaker. We actually use it a lot at my job, but I don’t because I can’t access it remotely from a Linux server. Not sure if that’s a quirk with the FileMaker server security we have or a lack of support.

I also tend to avoid it because it’s halfway in between Access and a real SQL database (Postgres, MySQL, etc). But also — have you seen how expensive it is? If you want an individual license, it’s >$500. Or you can get a subscription per user per month.

FileMaker seems like one of those applications that Apple has never really known quite what to do with.

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

#328
post #60

Earlier quoted context omitted.

Re: Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Because existing web UI standards suck rotting ass to hell and back. The standard was not meant for CRUD and still isn't even if you add gajillion layers of (buggy) JavaScript to emulate a real GUI. We! Need! A! Real! GUI! Standard!

Just master rails -g and you can be done in an afternoon.

I agree that if you tune it for shop conventions and know its warts well, one can indeed be productive in it. But getting to that point is not necessarily short or easy.

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

#329

Earlier quoted context omitted.

Being able to automate forms can absolutely revolutionize some businesses. Many business owners have no idea the extent to which automation is feasible here. I have seen fully manual paper process (printers/scanners/pen & ink/shredders/etc.) go into 100% digital realm and the impact it had on the business. It really is incredible the difference it makes. The most interesting factor was the fact that now that the inpu…

> Being able to automate forms can absolutely revolutionize some businesses I once worked for an insurance brokerage whose in-house CRM had started years before as an effort to automate paper-based forms. The company's business model was based on having their sales advisers fill out insurance policy application forms on their customers' behalf and originally this had been done using pen-and paper, which was obviously…

> While the idea of superimposing HTML input fields over a scanned paper form isn't one I've encountered before or since, that company was turning over $3M per month by the time I joined, so there is clearly mileage in the idea.

You can also do this with PDF files, if you have Acrobat (or at least, it was possible - last time I played with it was several years ago - 2009-ish).

You've probably seen "editable" PDF files - where there are fields you can type stuff into - much like a paper document that you'd put in a typewriter to "fill out".

Well, it's actually possible (in Acrobat) to set up a "form submit" (virtually identical - IIRC, it was an actual HTTPS POST message) that you could point to a web endpoint. Add a button to the bottom of the page to submit the form, and it could also capture and handle errors (like if the service to receive the POST is offline, or has an error, etc).

I forget was Adobe called it - but it worked rather well. I worked for a web app company who was contracted by a doctor's group to redo their website, and part of that was automating the forms. They wanted some way that a patient could download and use their standard PDF forms, to both enter and upload the information, or print it and fill it out manually and return it, if they were more comfortable with that.

They didn't want an standard web form, or anything like you mentioned - because they might change the PDF for manual copies. Instead, we supplied them a template and taught them how to use it (and not to change particular parts - the parts handling submitting/errors and such) - so they could continue to use it. The backend was a PHP/MySQL system, everything was HTTPS, and IIRC we encrypted the data on the backend. I'm not certain that it was completely HIPAA compliant, but it was certainly as compliant as "form filled out with pen and filed in folder).

So yeah - there's clearly a market for this kind of thing...

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

#330

Earlier quoted context omitted.

Being able to automate forms can absolutely revolutionize some businesses. Many business owners have no idea the extent to which automation is feasible here. I have seen fully manual paper process (printers/scanners/pen & ink/shredders/etc.) go into 100% digital realm and the impact it had on the business. It really is incredible the difference it makes. The most interesting factor was the fact that now that the inpu…

> Being able to automate forms can absolutely revolutionize some businesses I once worked for an insurance brokerage whose in-house CRM had started years before as an effort to automate paper-based forms. The company's business model was based on having their sales advisers fill out insurance policy application forms on their customers' behalf and originally this had been done using pen-and paper, which was obviously…

HTML is an amazing approach for fully-generated forms. But, for filling pre-existing forms, the mapping from HTML down to fixed layout on an existing document can cause lots of headache when it comes to getting really precise positioning of elements within dense forms.

We built an internal tool that effectively converts any business form into a PNG @ 300DPI, and then defines a fixed element layout on top. This allows for pixel-perfect positioning of elements you'd like to fill on top of literally anything you can get into a PNG. Each definition is effectively just a JSON model specifying where everything lives, and then it is fed into some C# System.Drawing routines to fill the template image with expected data. The output is then converted back into whatever format is most ideal for downstream delivery (i.e. merge PNGs back into pages in a combined PDF).

The downside of this approach is that rasterization of PDFs or other upstream forms items effectively strips them of any textual data that you could mine out of the document. So, there are certain use cases where this would be a bad approach. For most businesses, I don't think this is usually a concern, especially if you already have the data you used to fill the document in a good structure somewhere for alternate delivery approaches.

Post reply on HN