Comment by eterm | Hacker News Reader

Comment by eterm | Hacker News Reader

Parent Full thread

Despite the fact I've long moved on from MS Access, I know exactly what you mean. There needs to be an application that anyone can open up and start doing database stuff with, that is cross platform but accessible to both end users who want to explore through clicks (query builders) but also those who want the power to script it (SQL and VBA).

Access really delivered on that count. If it wasn't for the two factors of relatively poor performance (terrible performance when run "across" a network) and lack of cross-platform behaviour, it would be my go-to tool.

I think there really is demand for a cross platform database gui that sits on top of a serverless database file. If this file can be uploaded to a website that also enables excel-like data manipulation and then downloaded/shared back as a file for manipulation by this gui tool then even better.

If this tool is powerful enough to realise that it shouldn't try to execute across a network and somehow flip over to a "remote execution" mode where it targets a server rather than a file, then even better.

That's the dream, nothing has ever come close.

Opening an MDB across a network share. Opening large databases for long running simulations was par for the course at a company where I previously worked. One of the first things I did was make sure files were on a local drive before simulating which turned a 6 hour run into a minute long run.

SQLite backend and <Frontend in Any Language>. What's the big deal?

Access is the frontend

Ah yes, Code: It's Trivial[1]

Jeff Atwood quoting Benjamin Pollack

" Developers think cloning a site like StackOverflow is easy for the same reason that open-source software remains such a horrible pain in the ass to use. When you put a developer in front of StackOverflow, they don't really see StackOverflow. What they actually see is this:

  create table QUESTION (ID identity primary key,
  TITLE varchar(255),
  BODY text,
  UPVOTES integer not null default 0,
  DOWNVOTES integer not null default 0,
  USER integer references USER(ID));
  create table RESPONSE (ID identity primary key,
  BODY text,
  UPVOTES integer not null default 0,
  DOWNVOTES integer not null default 0,
  QUESTION integer references QUESTION(ID))

"

[1] http://blog.codinghorror.com/code-its-trivial/ Appropriately enough the blog is complaining about the attitude being displayed on Hacker News

The big deal is that in an office you tend to have access to the following only:

* Microsoft Office (slightly out of date version) * Internet Explorer 8 or less * Adobe Reader * Crappy SharePoint installation

If someone can find a way to replace Access that doesn't involve going through corporate IT's 50-year long approval/installation process, it'll be a massive hit.

Or find a job at a more agile company.

That's beside the point. Yes, if you don't want to deal with Access then you can go and find a job at a smaller, more agile company.

However, there are always going to be a lot of people who do work in vast, stuck-in-their-ways corporations - banks, energy companies and other MNCs.

An Access replacement would be aimed at these people, not a specific individual who could just 'find a job at a more agile company'. As a result, it could be very successful.

That's called Monopoly. It has nothing to do with Access. OpenSource Alternatives exist since Star Office days so it can't be said some alternative of Access don't exist

Uh huh. And the important part of Access is the front-end. And no one from the open source or hacker community has even come close, not even in the same ballpark, not in 20 years now. Twenty years!

So clearly there is, in fact, a big deal. If you think you can write Access in a weekend, feel free, post it here when you're done. Good luck!

I've never used MS Access before. What is the difference between it and PHPMyAdmin or HeidiSQL?

What specific things made MS Access so easy to pickup and what made it powerful?

For anyone else that is looking for what was described above, I'd be pretty happy to work on something new for a change.

If you can please provide me some details (my email is in my profile), that would keep me motivated. My only gap in knowledge is MS Access and what it did well and what it didn't do well.

the form builder. Takes about 30 mins to get a form front end built that ordinary users can use by double clicking. You can customize quite like crazy with VB script.

My experience was 8 years ago, its just so easy to hack something on a whim to solve some office task that's annoying (for internal use only, the security was a joke).

The graphical database designer tool was perhaps useful for non-techies too. And the forms could be extensively customized with VB script if it didn't do what you wanted out the tin (change this color when X happens etc).

Excel, and Access specifically were unique in that they helped groups validate their need for software. By the time they had given in and tried to build something themselves, be it in excel, or Access, it allowed the logical extension of 'here's the data we need' to 'here's how we need the data to connect and interact'.

I think anyone who inherited an access system saw the progression from taking an excel like interpretation, to putting forms on front of it, to trying to connect the forms, to ultimately print some form of report. It was CRUD within one app, that didn't require learning 37 different technologies to make one screen work.

At most, you might have to pick up VBA if you wanted to do something fancier.

As much as Access makes me cringe, seeing the apps that were reasonably well architected and talked to MSSQL backends didn't look too out of place.

I've not used either of those tools, but here's some stuff that access does that I often find lacking in other tools:

1) You can copy a grid from excel, do a "paste as data" and access will automagically create a table, with the right data types and even pick up column names if headers are present.

2) You can view a table as a grid, similar to excel, and just start typing away to create data. You can do this before you even create the table to just start creating a table.

3) The drag / drop query builder is extremely easy, especially for things like cross tab queries. You can click "view as SQL" to then turn it into SQL if you want to tweak stuff. (I actually learned SQL this way)

4) foreign keys are made through a drag-drop interface "relationships"

5) The form wizard makes making forms really easy.

6) You can right click a row and delete the row. You can right click a column and delete the column. Any error messages are typically understandable and not cryptic.

7) All your data is in a file. A file which you know where it is, and you know you can click that file to open and see your tables and forms.

8) You can save queries which act almost like views / CTEs and in most queries you get a grid which you can just start editing data in if you so wish.

If anyone is unfamiliar with access I'd strongly recommending getting hold of a copy to play around with, it's how to do database right for end-users.

I never found the GUI query tools to be particulary intuitive once you moved beyond single-table queries. GUI or no, you still need to understand basic relational database concepts to be able to set up multi-table joins in queries that actually produce the results you want.

In access an expert can set up relationships which will cause them to be automatically joined when a less expert user adds both tables to a query.

Some knowledge is usually required to make sense of the results though but I'd say a non-expert still has more chance with access than any other tool.

I learned about relational databases just from playing with Access at one of my first (boring, nontechnical) jobs. Just the fact that the GUI gives you a valid query for multi-table joins, even if it's not the one you want, is extraordinarily useful if you don't know SQL and want to poke around.

The other responses are on point, but I'd add that Access made it super-easy to share database apps, since they were just a file (or files). No servers, etc. Just email it over, or drop it on the share. For the typical Office user, using such a file didn't involve installing any software or setting up any servers. Distribution was super-easy with Access.

PHPMyAdmin is too low-level for what I'd want. For myself, it's fine, but I can't just hand it over to users for querying, updating, adding records, etc. With Access or Filemaker it's easy to set up something that I can hand over to nontechnical users. When I want something web based, I always seem to end up having to code an interface for it myself, which feels like a waste of time.

The GUI - it looks like and works like souped up excel. If this is something you're working on, buy a copy of Access and play with it for a few hours.

PHPMyAdmin and HeidiSQL are administrative tools for managing your database. MS Access was an application development environment and database combined. Access was full of GUI's and "wizards" (the interfaces where you answer some questions, click next, answer some more questions, repeat until finished).

The result was a tool that power users (users who are very good with a computer, but not a full fledged programmer) could use to build some pretty amazing stuff.

It has been mentioned elsewhere in this thread, but one of the amazing things about Access was the way it could figure out what you wanted to do through a wizard. Provided your tables and relationships were set up correctly, you could do some powerful stuff. For example, if you have two tables with a 1:many relationship, you can display a form with a sub-form where the data is linked. Navigating between records in the parent form would automatically load data in the sub-form.

It's a product that you really should use a little if you're really interested in a project. Despite its warts, Access was a really incredible and ambitious product.

Reply on news.ycombinator.com