Yeah - people basically had entire applications written in Access - think very simple point-of-sale systems, record keeping tools etc. The downside of course, is that, it ran on a single computer and there wasn't a concept of multi-user systems (or maybe there was and I just wasn't aware of it).
In some ways, it's a hark back to the day of a really 'thick' client that was a server, middleware and client all in one.
Access scales from being a one process all-in-one solution to multiple processes sharing the same database file and also to a separate ODBC-connected database engine with Access as a frontend. At least some 20 years ago, there was an assistant to automatically migrate an Access database to a split Access/SQL Server setup.
If I had to throw together a reasonably robust data entry form in a time crunch today and could connect to the DB engine via ODBC, I'd probably still use Access for that.
Comments
Yeah - people basically had entire applications written in Access - think very simple point-of-sale systems, record keeping tools etc. The downside of course, is that, it ran on a single computer and there wasn't a concept of multi-user systems (or maybe there was and I just wasn't aware of it).
In some ways, it's a hark back to the day of a really 'thick' client that was a server, middleware and client all in one.
Access scales from being a one process all-in-one solution to multiple processes sharing the same database file and also to a separate ODBC-connected database engine with Access as a frontend. At least some 20 years ago, there was an assistant to automatically migrate an Access database to a split Access/SQL Server setup.
Looks like there are some additional configurations that MS actively supports: https://support.microsoft.com/en-us/office/ways-to-share-an-...
If I had to throw together a reasonably robust data entry form in a time crunch today and could connect to the DB engine via ODBC, I'd probably still use Access for that.