Hacker News Reader

Comment by mamcx | Hacker News Reader

The reason is even bigger than just VB.

MS at the time just decide to fully kill the "enthusiast" developer and the "single/truly small" team developer. This is mostly covered under the "RAD" umbrella.

It kills VB, FoxPro, and now more evidently, Access (more like let it slowly die).

.NET + Visual Studio + Sql Server are not a substitute in this market. Them are for "professional developer"/"a small cog in a big machine". The worst part is that this move somehow kill the other tools in this space (because somehow others follow suit or whatever) and without somebody leading the charge to see how adapt this tool for the web. MS not getting the Web, Borland doing Hara-kiri and others getting annihilated by "free" open source and all that not helps.

Ironically, this market have rebound in the myriad of tools like "low code, notebooks, etc" that fill (badly!) the gap.

View on HN

Serious question: what is a good alternative to Access (edit: to build a GUI frontend to a database)? The database design tools and basic forms were incredibly easy to use, and there were very good tutorials for everything else. LibreOffice Base is different and not even close in comprehensiveness, and there seems to be nothing replacing it that isn't a super expensive SaaS.

For a long time I would have said FileMaker, but considering the strategic moves of Claris in the last few years probably not anymore

Filemaker?

The parents point is that there is no alternative, because everyone left the market chasing Microsoft.

SQLite. It's not close in terms of ease-of-use of the GUI administration and forms, but as a single-server database solution to embed into a line-of-business app it's fantastic.

The GUI and forms is what made Access, though. Back in the day I actually made a system with Access that connected to a SQL Server database on the backend rather than Access's file-based engine.

It's a real shame Access died, now there's no path from a spreadsheet to something more sensible.

> It's a real shame Access died, now there's no path from a spreadsheet to something more sensible.

Although it has certainly died in terms of mindshare, it's officially still supported for PC (not Mac):

https://www.microsoft.com/en-us/microsoft-365/access

I actually have it installed right now, because it comes with Microsoft 365 Family, which I have on the Windows PC on which I'm typing this comment. I haven't used the modern version of it, though.

...it's fantastic if you are able to live within its limitations, primarily being a single writer.

If your application grows into the need for concurrent writes, then it will be time for another database.

You may be surprised at how far you need to grow to truly need concurrent writes. Blazing fast sequential writes is good enough for the vast majority of applications

I know how to write a Django app with a SQLite backend, but that's not what Access does.

There are basic SQLite GUIs, but they have no reporting functionality and no customizable forms.

This is so true.

A cross platform Access-like front-end that used sqlite as the data storage engine would conqueror large parts the territory.

Airtable is the closest I have found for ease of use - users that don’t know SQL can put together basic queries and views quickly.

1000 records per table on the free tier is ridiculously low, it basically makes many to many relations impossible. It also doesn't have reporting, and I have no need for attachments.

Equally serious question: what is the use case for Access?

It's been installed on every corp workstation I've had and it's never been useful. In my experience either Excel can do it or you need a real programming language/database.

Access was an app you had installed on your workstation but never opened because in the backend every late 90s early 2000s desktop app was using it as its data backend.

Between Excel (with no functional API to use for storage) and a "real database" (your users now need to ask IT to deploy SQLServer) was a use case of app just needs to store persistent data for a single user.

I remember there was at least one video game (some turn-based tactics game, don't recall the name) that had Access as a savegame format. It was very convenient to edit the save file.

So basically the SQLite of its day?

Acess allowed you yo build small forms/apps fast.

Those business apps made "by that one person" that allowed few other to input data concurrently (back then no google sheets / shared Excel... which are horrible and have no user defined GUI) and then to make reports.

Also data manipulation when it didnt fit Excel (I know access has 2gb limit, but it was a lot).

SQLite with a somewhat usable GUI ...

Access allowed maintained "relations" between tables, so you didn't need any code to have a master/detail relationship between tables, it just handled it all. This carried over to forms, queries, reports, etc. You could have a system with data entry, master/detail records, queries and reports built in a day, all without ever doing any SQL.

Through ODBC, you could connect to pretty much any database around. I think Office 2000 Professional was one of the best products Microsoft ever produced, it's all downhill since then.

Past tense? For PC users (not Mac), it's still supported and included with Microsoft 365.

I don't have Office 365 any more... so I wasn't sure... Microsoft seems to slowly be killing functionality in everything, so I couldn't be sure.

Also, things went downhill when they got rid of full menus and introduced the accursed "ribbon".

Access had a very low barrier to entry and sanitized inputs. Excel doesn’t cater to minimally skilled people who want to hand off forms to someone else for data entry.

Why is this zip code a phone number? It’s not the users fault, your using the wrong tool.

I know of small companies and charities that would use Access as their homegrown CRM back in the 2000's. It worked really well, you just needed one guy who'd be willing to set it up and they'd be good to go with the basic forms for a couple of years usually.

It's definetely not great by todays standards when it comes to backups and what not, but it was really fantastic at the time.

I used it to create a detailed opinion of cost with recursive summing, so that item costs were summed per section, section costs summed into summary costs, summary costs summed into project cost.

No other document designer that I'm aware of allows for runtime integration of variables into the layout/presentation.

Prototyping - occasionally when starting out on a big in-house development project, we'd task one or two guys to build a prototype in access to understand the challenges, functionality, data issues and get user feedback on what worked and what didn't. Invest 3-4 weeks of effort that saved us months of effort from the project overall and de-risked the project substantially. One time it back-fired a bit when the users liked the access proto-type more than the final system (pushed the envelope a bit too much and the performance was very poor), but typically got plenty of value out of it.

Seen a lot of screw-up by someone taking a databse export (csv or whatever) into excel to work on it, sorting but only sorting one column leading to disaster.

This is just unbelievably /common/.

maybe SqlServer Express ? It has limits on memory and DB size, but if your project is small it might suffice, in conjunction with Management Studio Express.

I've never used Access so apologies if you're looking for more than a GUI-driven interface to the DB.

SQL Server Express is just a (fairly generous, last I looked!) limited version of the full SQL Server.

So, it's a substitute in terms of affordability. But absolutely not in terms of "rapid GUI application development" for the non-programmer.

It is not. Access was easy to build the app on top of a reasonable database seamlessly, integrated, visually. SQL Express is just the database part and there is nothing that integrates so well on it like Access does internally. Access is not powerful enough for larger databases, but boy it was easy to use for small ones.

PowerApps probably, and with the transition to the cloud Microsoft will probably not invest too much into stuff that can't run well in a web browser and mobile app.

A monthly subscription is a non starter for charities and also it needs a work or school account.

Last I interacted with Microsoft they were quite generous here. They have special pricing for non-profits and they definitely have a whole different structural thing for schools

There is no good alternative, really.

LibreOffice Base is... okay. It's not great but I was able to do most of the things I used to use Access for (simple small CRUD database tools that let you quickly build forms, simple table relationships, enter/review data, generate reports). Basically, it's better than nothing and nothing is what we've got now. Base can get pretty confusing at points and has given me a lot of head-scratchers at some times.

Even with otherwise seemingly easy-to-use web-based improvements to Excel that my employer has like smartsheet... these don't seem to let you do any sort of super basic many-to-one relationships (maybe with some expensive ad on package? dunno... and smartsheet has plastered their site with a bunch of 101 intro to databases SEO spam that explain what different types of relationships are rather than how to fucking build them with smartsheet)

> what is a good alternative to Access (or Fox, I add)

Nothing.

Access is(was) in fact a worse alternative to Fox:

- Much worse DB engine, and that is saying a lot (FoxPro db can and get corrupted. A typical functionality that was added to any fox codebase was a utility to fix it)

- MUCH MUCH worse programming language (VB) that is neither good as-is, much less as a data-programing language.

Fox/dbase is the only data-oriented language that was relatively popular and fit for the use-case.

This is by a mile the main point: Is a desert looking for languages that are made for business app/data oriented programing (and much harder looking for something not weird).

The main options: Fox/dBase/Informix(? not remember), kdb+, Cobol, SQL(when extended as store procedure lang with loops and that)

This point is big. Having a good form builder (that is already rare) is not enough to be a real contender for this space. You need a language where making queries is truly nice.

In short, you need a language that is `LINQ/Relational` as first-class end-to-end.

- If this lang needs an ORM: FAIL.

- If this lang needs to compose strings to make a query: FAIL.

- If exist "impedance mismatch" between data manipulation/queries and the rest of the lang: FAIL.

- It should also support super-advanced types like date, decimal, currency and ideally dimensional units. Ideally algebraic types as today.

- It should have a version of Rust `serde, Into/From` traits, for easy conversion between data + formats.

- It should look "normal" like python/swift with `LINQ` queries.

This is the lang I trying to build: https://tablam.org

Looks alot like Lua!

and thats not a bad thing per se

As someone who loves LINQ, this is really cool, best of luck with your language! There is certainly a void that is waiting to be filled by such a language.

Although as other said on this thread, the real killer feature would be a form builder as in foxpro etc. It can be somewhat primitive, as long as it's easy to build and extend. Ideally the forms should be web based.

Sure, the UI side is pretty important!

But I try to get a good companion for it, so it get good synergy.

Maybe:

a) https://www.nubuilder.com

b) https://gambas.sourceforge.net/en/main.html

Also:

c) https://github.com/twinbasic/twinbasic

Once it gets out of beta.

Budibase looks really impressive, basically a GUI frontend builder for postgres and its open source. Haven't actually deployed it, but played with the GUI builder and its nice.

There's a few other similar ones out there too like Baserow [2], Appsmith [3] and nocodb [4].

Finally, if you wanted a step up, then I guess supabase [5] would be the next one up but its more like "I just want to write front end and have auth, database, API and storage taken care of for me"

But none of these really give you that all-in-one database and front-end via files like Access did and its a damn shame. Yeah I know Access lead to some god-awful applications, but honestly the people complaining about shadow IT don't realize that its inevitable if IT isn't fixing people's problems. You just need to be clear that if the business unit goes down that path, they're on their own. So if the guy who built your crazy Excel VBA app is gone, don't expect that to be picked up by others just because its super important. But, if it is in fact that important, then its probably a prime candidate for actual development work, so the duct-taped together things do end up being sort of testbeds for whats actually important.

The whole lowcode-nocode shtick is a bit oversold, but one good aspect of it is that if you allow for an easy onboarding sandbox for the type of person who would otherwise make an Excel VBA app, at least some of these platforms have sandboxes with guardrails and other compliance stuff you can apply.

[1] https://budibase.com/ [2] https://baserow.io/ [3] https://www.appsmith.com/ [4] https://github.com/nocodb/nocodb [5] https://supabase.com/

At least Access has a sound model underneath. Excel is nothing but a damn grid, while Access has tables, keys and constraints _and_ a visual GUI builder on top of those. The development environment was an only slightly pared-down Visual Basic but it was fully integrated in the rest of the GUI, while VBA always felt like it was tacked on the rest of the application.

Check Filemaker. A friend of mine is a 100% Filemaker freelance. Apparently it can also generate web sites over the data in its db.

Jesus Christ, not FoxPro.

I briefly worked for a company whose main product had been a FoxPro application that they rewrote piece by piece in C#, reimplementing various FoxPro idioms as they went. It was a nightmare and no one knew what any of it did. One "senior" developer tearfully argued with me during a code review that even fixing comments could have dire consequences.

I suspect that someone higher up liked it that way, because I was fired shortly after mathematically proving that something was really wrong in some of the accounting code.

Well, no programing language is good for data applications as is FoxPro (certainly not C#), and is terrible to writer LANG-a in LANG-b.

So sorry for you to get the worst of both worlds!

P.D: I do a port from a Fox app using idiomatic C#, like 10-30x the size of it, but well it was idiomatic!

All the consumer products were killed, like Encarta, games, Microsoft home stuff. MS went full enterprise.

Vscode supports many enthusiast development stories.

Reply on news.ycombinator.com