Could be bad or could be good…
I moved into Access from a background in Oracle, Informix, DEC Rdb, etc. We had a business dealing with organisations covering 10 to 100 concurrent users or so, perhaps $4-20 million allowing for Inflation. I’d put together a few Access based tools for limited use. Many of us were using VB, or PowerBuilder. I had put together a proposal where we were asked to move one of our green screen BMS over to Windows 3x. It was a combination of top-down and bottom-up, and the customer wanted an idea of what it might do. I put most of the screens and reports they wanted in Access 2.0 rather than just sketching them out. The demos went pretty well, with a few suggestions for changes. I went back a couple of days later with the updated screens and reports. The customer asked when we could install it, I said it was a demo only, and it would be rewritten in something else. Why? He said, it works, we played with it while you were doing the changes. I explained that it would need more memory than some of his PCs had, and it wasn’t designed for multiuser operation. Could it work? He asked. I thought it would take another few days, so he said they would pay for that - irrespective of how it went.
I split it into a front end - containing the forms, reports, and code; and a backend holding the shared database, we ran it on 3 of his PCs. He then agreed to upgrade the memory on several more computers, but noted that the MS Access license cost was pretty high - The runtime version had just come out, so I told him that if he gave me another couple of days, I could modify it. The whole thing fitted on a few floppies. Eventually it ran their whole business, and when SQL Server could be used as a backend we moved it over.
What we took from that was we could write a stable functional system in a couple of weeks. An Access backend was good for ~30,000 rows, with up to about 10 referred tables and 5 active concurrent users. The MS shadow locking schema required a stable network (later WiFi networks were rubbish). The SQL Server backend needed queries etc., rewritten as stored procedures, views had to be on the server, and it would easily scale to a couple of million rows by changing how combo boxes etc., worked and 30 or so active concurrent users were fine (it was OK on WiFi LANs too). That covered all of our user base. We looked at VB again for deployment on PCs with limited memory, but Crystal Reports was dreadful, buggy, and slow; whereas the simple banded Access report writer was faster, prettier, and for large data sets required less memory than Crystal. One thing we learnt was that the learning curve for Access was longer and steeper than we initially thought; but once mastered, product development times were very short, allowing us to undercut many competitors and make money
From that point on, even when we quoted with additional memory, we were still inexpensive; and for a time, one of our products was a Microsoft Reference Site.
We started putting stuff out as shrink-wraps, and realised that most customers didn’t know or care that it was Access. After I retired, the company continues. One of our products was first written in 1995, and has been regularly updated since then to the latest version of Access and SQL Server; and, the last I heard, was that it was on >700 active sites. Rough rule - know the limitations of your tools, and allow for them.
I still do a bit of pro-bono work, mostly SQLite based LAN web servers for a few concurrent users; and haven’t found anything as fast, or productive as poor old Access.
