Sorta like Excel, then?
And yet, so much of the world runs on excel spreadsheets being sent back and forth. Why? Because 1) it has a low skill floor and very high ceiling, 2) everyone uses the same tool (or at least it's backward and forward-compatible), and (critically) 3) it has a "programming model" that actually makes sense to the vast majority of people.
Same with Arduino, by the way. I think Arduino is a masterpiece. It allows people that don't even consider themselves programmers to write code for embedded systems with ease (traditionally a very hard thing to do). They go to the Arduino website, download a program, open an example, click a button and it works.
Also, the libraries are designed to be used by non-experts. That's so rare in the software world (and I don't know why*).
* I have some guesses but they are not nice to the programmers that make and use trendy software libraries.
I read somewhere that there are 10 x more Excel "programmers" in the world than programmers for all other languages put together.
I not knocking spreadsheets- they’ve obviously stood the test of time. I feel their weakness is that the formulae are hidden and you’d need to click on individual cells to make sure their isn’t a logic error.
But there's a massive usability gap between downloading an application and "open the command line, run pip install jupyter, oh pip is not installed, google the error message, copy and paste this command from a random website, try again, etc". It's better now with JupyterLab Desktop, but that's only been around for a few months.
I just wish Microsoft made the whole experience a lot better as writing VBA is a bit confusing.
Edit: 2gb!
It worked quite well for several years, until of course I reached a limit (which was much smaller than 4GB), and I had to delete old posts.
The thing that imposes these limitations is the somewhat primitive DB engine for Access, which is codenamed MS Jet:
https://en.wikipedia.org/wiki/Access_Database_Engine
But the big that MS & MS fans don't like to mention is that MS Exchange Server uses a version of the same storage engine.
It's not mentioned even once in these Wikipedia articles, for instance, but if you look, you will find telltale giveaways such as Exchange store size limitations:
https://en.wikipedia.org/wiki/Microsoft_Exchange_Server
https://en.wikipedia.org/wiki/History_of_Microsoft_Exchange_...
However, if you dig a little, you'll find that the underlying storage engine is also codenamed "Jet":
https://en.wikipedia.org/wiki/Extensible_Storage_Engine
Jet Red vs Jet Blue. Totally different, honest.
These days, it's also used in trivial unimportant Windows subsystems such as -- er -- Active Directory, Windows Update, and the Windows Search indices.
Yes, the fragile, essentially single-user, easily-corrupted Access DB engine is an integral part of Windows Server.
Which is a bit odd considering MS also owns SQL Server (bought in from Sybase), and could in principle use that instead, which does not have these built-in limitations and is rather more robust.
Access was in part built in response to Lotus Approach, which brought Claris Filemaker-like simplicity to Windows end-user databases. MS could not tolerate that, so built its own Approach-killer, which was vastly more complex. It acquired FoxPro, a dBase III/IV clone, for its very fast indexing functionality, which was bolted onto MS Cirrus to make Access, and the rest of FoxPro went largely unmaintained until it could be discontinued.
Exchange Server of course replaced MS Mail, which was also bought in and was previously called Network Courier from Consumers Software. Other MS purchases include Powerpoint, Frontpage, Visual BASIC, and Visio.
There is a general pattern evidence in 1990s MS software which isn't universal but widespread. If it's lean, mean, simple, fast, or elegant, it was bought in. If it's overcomplex, fragile, has bizarre limitations for non-obvious reasons, and needs careful maintenance, it was built in-house, probably in response to a successful competing product.
(I was a certified Exchange admin, in the 1990s, and have cleaned up several big corporate systems that collapsed.)
It is not the tool you want for business-critical shared network data stores.
And yet, the pairing of Exchange and Outlook is THE MS critical tool that's won them a million corporate accounts.
That's a million corporates, of course. Not seats. Hundreds of millions of seats.
IIRC there is an easter egg in Microsoft Access 1.0 where the About box changes to an animation of a pond with two ducks in it that are then hit by lightning from a cloud above. I.e. a cirrus and a 'pair of ducks'...
Yes, true. I was never a database guy but my impression at the time was that this was more of a capable tool for pros who wanted to do machine-local standalone stuff, whereas Approach won reviews and tests for ease of use.
OTOH saying that I've seen amateurs do amazing stuff with Access by trial and error....
> IIRC there is an easter egg in Microsoft Access [...] > a cirrus and a 'pair of ducks'...
:-o That is harsh!
Either your data is small enough to be managed by Excel or your data is complex enough to be better served by a database and frontend.
Dealing with the idiosyncrasies of Access is never worth it.
I use it for a few hobby things and it's fun. Drag and drop a few things in a form, add a couple fields and you're good to go! Sure beats having to write SQL by hand and a few hundred lines of Python to interface with it; and that's before you write the UI for it.
I wish MS would spend a little bit of that R&D budget to improve on it some more, and expand its capability. But that'd cannibalize their other products, likely. It's too niche nowadays.
If you want your data centralized, with the application being a portal to that data, you use a database with a frontend built in your choice of language.
If your situation has reached the point where Excel is no longer a workable solution, you need a full application. I've never seen an Access application that didn't grow to a point where it wasn't a glitchy mess requiring a rewrite as a full stand-alone application. So you might as well skip that step and go straight to the stand-alone application.
It's an unnecessary bridge.