> it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer [...] Access did support a client-only mode, where Access is used for the forms, queries and application code, but the actual data is stored in Microsoft SQL Server
Both your comment and a sibling's mention features that Access either didn't have or didn't do well. However, there were low-code/scripting workarounds for all of these, which were in fact used in many places. It was scalable if you were just knowledgeable and persistent enough to keep chasing your goals. In addition, the backend didn't have to be SQL Server, it could just be another Access database.
I myself created a 'sharded' Access-only implementation (admittedly a fairly simplistic one) that supported over 300 concurrent users. The trick was to keep record locking to a minimum by training users to click a 'save record' button when they were done filling out a form (which defaulted to an offline state)-- all the data was then uploaded to the central database in a few milliseconds, and the connection was immediately closed. Kind of mimicking old webforms. It worked.
> IT programmers invariably cursed the buggy hack of an application they had to maintain
This was really the biggest problem. Only apps designed by people who were pretty good at what they were doing avoided this.
Both your comment and a sibling's mention features that Access either didn't have or didn't do well. However, there were low-code/scripting workarounds for all of these, which were in fact used in many places. It was scalable if you were just knowledgeable and persistent enough to keep chasing your goals. In addition, the backend didn't have to be SQL Server, it could just be another Access database.
I myself created a 'sharded' Access-only implementation (admittedly a fairly simplistic one) that supported over 300 concurrent users. The trick was to keep record locking to a minimum by training users to click a 'save record' button when they were done filling out a form (which defaulted to an offline state)-- all the data was then uploaded to the central database in a few milliseconds, and the connection was immediately closed. Kind of mimicking old webforms. It worked.
> IT programmers invariably cursed the buggy hack of an application they had to maintain
This was really the biggest problem. Only apps designed by people who were pretty good at what they were doing avoided this.