|
|
|
|
|
|
by unscaled
561 days ago
|
|
|
Microsoft Access definitely took off. It was certainly more popular than the new crop of no-code/low-code platforms we have today. In the late-90s and early 2000s almost every large company seems to have had Access applications running in several different corners of the business. The reason Access eventually died off is that it wasn't designed as a multi-user database. You could run Access on a network file share but performance would suffer (especially with concurrent access by multiple users), and you'll be running the risk of database file corruption. Microsoft 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 — but setting up and maintaining a database server was probably too complicated for the type of contexts in which Access became popular. The key point is that most of the usage of low-code products in the past was basically an instance of Shadow IT. In order for a Shadow IT product to be successful it generally needs to be easy to use, easy to distribute (or access) and have a capable free (or effectively free) version. Access and Excel had it all. They were easy to use for beginners (although complex applications required skill). Distribution was extremely simple in the corporate intranet age: you just had to place your Excel or Access file on a network share. They were part of Microsoft Office, so everybody had them on their computer "for free". If a product fulfills the conditions above, entrepreneurial employees will start using this product to address viable needs that your IT department lacks the resources to solve with a more robust solution. Often these Access apps became popular enough that it had to be officially taken by the IT department, where IT programmers invariably cursed the buggy hack of an application they had to maintain. I don't know the statistics, but I assume a great number of these would just be rewritten as a traditional client/server or web application. |
|
|
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.