Microsoft Access finally breaks free of its 22-inch form limit Microsoft has demonstrated that there is life in the old dog yet with an update to the Access relational database management system that addresses a limitation stemming from the days of cathode-ray tube monitors. The fix, currently in beta and set to roll out in the Current Channel preview by July 21, 2026, removes a 22-inch …
fortunately I have never had to deal with it but I have never heard a good word uttered for it — mostly curses with the afflicted fleeing to FileMaker which from my limited exposure seem to require very peculiar, if not sordid, tastes.
Enterprise's "if it ain't broke, don't fix it" credo is gazumped by MicroSlop's "if it's ours it's always broken… let's break it some more."
We have people who skipped Access completely and started with Excel, now they've got whole departments limping along with gigantic excel sheets that nobody understands because the people who set them up left long ago.
Occasionally one of them loses their data because nobody seems to understand that when someone leaves their SharePoint or (shudder) OneDrive gets cancelled and eventually deleted, so the whole department grinds to a halt while it's recovered.
If it can be.
My first job out of university was on a multi-year contract in an office where a coworker “learned” Access for grad school and created a database that was essentially an Excel file with static image references and a GUI that a disturbed child would have made to catalogue their collection of cat heads.
Being my first job, I didn’t want to make waves, so I said nothing when the process of editing the Access file was explained to me. You see, this database was shared with the entire office. And as one does when one needs to share a database, the method of sharing it was to place the file on a network drive.
“Now, wait” you say, “that’s a recipe for losing data and having work overwritten.” Silly you, spoken like someone who isn’t a database creator. My colleague explained his foolproof process thusly: “Before you go to work in the database, edit the file name and put ‘WORKING’ at the end, so people know you’re working, then when you finish, remove ‘WORKING’ from the file name so we know it’s free. Whatever you do, don’t open a file with WORKING, or someone will lose their work when you save it.”
I duly added WORKING each day and removed it each afternoon. Until around the fourth day, when, being that it was my first job and at a much sought after employer, I resolved to show how much WORKING I could do, spending the entire day painstakingly reviewing and editing a few thousand records. I went to close it for the day when a pop-up up popped. Access Wizard had edited the file, not only were all of my changes lost, but I didn’t even know when they were lost.
Panicked, I ran to his office and politely asked “Did you open the database?”
“Yes”
“But the filename said ‘WORKING’!”
“It said working all day, so I thought you forgot to change the name.”
From talking to IT, I learned that we had a site license for FileMaker that no one ever used. I asked to install it, then came in a few hours early the next morning and imported all of the Access records, and threw together a beautiful GUI.
When the department head came in (always one of the first in the office), I showed it to them and explained all of the benefits, not least being that everyone in the office could use it at the same time, and it would cost us nothing.
By the time Access Wizard arrived in the office, IT was installing copies on all of the office computers and setting me up with a server.
Access Wizard never forgave me for that. What followed was three years of endless backbiting and sabotage. When my contract came up, the department head informed me that I couldn’t stay on, because there was too much animosity in the office. They still wrote me lovely references for another decade, until they retired.
Thanks to that experience, I’ll always have a soft spot for FileMaker and a deep, seething, burning, fiery, incandescent hatred for Access.
Last I heard of it the FileMaker database was right before the pandemic when an intern reached out to me on behalf of Access Wizard to ask how to access the records. By that time, IT had finally dropped their license, so I offered to dump all of the records to PDF and CSV, but in typical intern style, they saw something shiny and floated away.
ETA: At one point during my contract, IT told me they wanted to get rid of the FileMaker license and asked if I would be willing to have them migrate everything to a proper SQL database. I told them that would be fine, but they would have to be responsible for dealing with my coworkers every time they urgently wanted to make a petty change to the GUI or tweak a report. They renewed the license instead.
As soon as I read: "My first job out of university was on a multi-year contract in an office where a coworker “learned” Access" my spideysense was tingling.
"..created a database that was essentially an Excel file with static image references and a GUI that a disturbed child would have made to catalogue their collection of cat heads."
uh oh.
"..this database was shared with the entire office. And as one does when one needs to share a database, the method of sharing it was to place the file on a network drive."
Oh my god, oh my god, oh my god, this post is about me!!
"“Before you go to work in the database, edit the file name and put ‘WORKING’ at the end, so people know you’re working, then when you finish, remove ‘WORKING’ from the file name so we know it’s free. Whatever you do, don’t open a file with WORKING, or someone will lose their work when you save it.”"
Phew, not guily of this bit m'lud... So that's me off the hook, but I am guilty of the other bits. I used to love Access, it got me out of a few sticky situations and improved several departments, yes the dbs themselves were shonky in the eyes of anyone who really knows about stuff but they were good enough at the time
I still use Access on a daily basis.
Our current ERM software has a Progress (not Postgres) back end, I have no developer access to the back end and the Progress Openedge ODBC connector has limited read only access. Our previous ERM software has a PostgreSQL back end to which I again have no developer access but at least the ODBC driver is read/write. Our Woocommerce website has a MySQL back end to which I have both developer access and ODBC read/write. All 3 databases are on cloud servers managed for us by 3 different suppliers.
Our website is structured round our previous ERM which can't be replicated in our new ERM. Also there is no API facility between Woocommerce and our current ERM. I use Access to batch add new items to the website via the old ERM software and also to update stock quantities and prices from our current ERM to the website. Using a mixture of data queries and VBA, I can pull data as required into Access running on an in house physical machine from each of the 3 external databases, process it locally and inject it back out to the website in a fraction of the time it would take to run cumbersome import/export routines from Progress and MySQL
I compare the ERM and website stocks and prices for 78,000+ items, identify which need updating on the website, update them and also export feed files for an external website index system, Google and Klayvio in under 4 minutes. Bear in mind our website accounts for only about 10% of our sales, eBay adds another 5% and the rest is bulk wholesale which is done directly in the ERM system, so the website can't control it's own stock quantities.
The fun bit is trying to remember 3 different dialects of SQL for the 3 different servers for when I occasionally remotely run quries on the servers, Progress SQL being very different from both of the others. Most of the processing is done in native Access queries and VBA, making development so much easier and quicker.
I read the two large volumes on it. You can actually set it up as an office automation tool for doing large amounts of work with other office applications.
I used it as a front end for SQL Server databases.
When the ISP got rid of Access for the database I moved onto SQL server and made a training booking system and prototype CMS (before those were a thing) for the website.
The training booking system took $300,000 worth of bookings but got retired when I was made redundant as no one could be bothered to maintain it.
but the fact that it's still used and maintained would seem to indicate that it's filling a need for a certain type of user. The use cases and users are not professional developers or database administrators, and I suspect almost all of the 'Access is terrible' commentary comes from that type of person.
Guilty as charged on being a dev.
I think you make a very good point. Yes, you can end up in a tar pit with Access. But it also addresses a need that is not met by traditional development frameworks, especially when it comes to entering data easily via a GUI. Excel fits there too. Hypercard, in case anyone remembers it.
Those tools empower end users. What comes after can be problematic but that’s indicative that our industry still doesn’t have a good story for end user productivity. Something that would easily spin up a front end with forms, serve it up on the web securely, hook it to Postgres and then run calculations with likes of Pandas or Polars. Then simple reporting possibly to an Excel spreadsheet. Oh, and version controlled too, plain text code files.
If I had to make a guess, Access line-of-biz apps will get replaced instead by LLM generated line-of-biz slop. And that will likely bring its own problems, though again this opportunity/need would be better addressed if we found ways to robustify end user creativity.
"Your Flexible Friend"
https://youtube.com/watch?v=S7N-tIqy6yQ
Pity that MS couldn't grab that slogan.
I've used Access in the past for quick data transformation and maintaining test data.
I built a lot of small line of business applications in various employments using Access in my time - those were built using the same discipline for database normalisation and coding standards as I'd have used if I'd been using SQL Server and oooh whatever the enterprisey forms tool would have been.
Access had lots of limitations and you could do a lot of damage with it but Excel and Word had that VBA engine in them too and I've seen things, things I can't unsee. Knowing the tool and knowing when to say no, not for this job is a large part of it whether it's Access or anything else.
It was the times we lived in - a PC on every desktop, an Office suite for every user, unleashing the power of the individual.... then we spent the next 20 odd years trying to put them all back in the box after the sugar rush to end it all. It's all wizzards innit ?
Back in the days before easy web interfaces it was a decent option for front ends, or at least a lot more decent than Java-based frameworks or huge Visual Basic projects. You could cobble together some screens and plop them in front of a SQL Server back end without a dev team and it could survive some growth with backups and multi-user lock support.
As part of a huge Y2K effort we had to deliver an app to search thru the documentation for all the new infrastructure and applications. Alas no one had budget or time to build it, so some interns were tasked with a read-only Access app to distribute. Worked fine for years. Horses for courses, not everything is nails, etc, but in the right place it was so much easier than the early java frameworks.
I've been working in this industry for >30 years, and my number #1 top tip would be Never, ever, EVER use Access in a business. I can't tell you the amount of times this has tripped companies up who I've worked with (who all made the decision before I arrived).
It's a familiar story: company is a startup, maybe one or two people (a handful at most), with little to no technical knowledge. They use the tools in front of them, which is Microsoft Office.
Access creeps in - a bit of stock is stored there. A few sales. A few customer details. Before they know it all the core functions of the business are stored in Access. Access is great - until it isn't!
Skip forward 5 years...
The company now has 50-100 people. The same Access database is sitting in a file share on a server. It's now critical to every function of the business. Sales - purchases - customer data - the lot. And you are FUCKED.
It's entirely file based - that means it fails big time when multiple people use it (and regularly crawls to a complete halt when trying even the most basic function). You've now built your business around a database that will routinely suffer file corruption and lost data as people edit in changes and save it over the top of existing data. That not enough? Did I mention the 2gb size limit. It's all fun and games until your entire database is UNREADABLE (not just writable). There's zero security - it's file based, so any employee can copy your entire business off the network and walk off with it and you're none the wiser. It's local to a file server - and now you want to open a second office (good luck). OH yeah - Access LOCKs the database (not the data) when you have it open - so now nobody is able to make changes to the database until everyone else has stopped using it (and you probably have 10/15 employees accessing it at a time). i could go on and on about the limitations - but you get the idea.
I've moved a ton of systems like this from Access to Postgres/SQL servers over the years (I've always tended to work for companies at this growth stage). Anyone who has done this will tell you what a nightmare it is. It's a lengthy process, complicated and there's a chance of data loss.
The longer you leave it, the worse the problem becomes. If you recognise any of the above, don't wait, jump NOW. Start the process today. It gets worse and worse and the problems accumulate, it never gets better.
Have you ever noticed how Access pretty much never changes? (so infrequently we get articles like this one when it does). Or why Access isn't included in Office suites on Mac, iOS, Android, etc? It's because it's a dead product that even Microsoft know simply isn't suitable for business. It's included for legacy reasons. Get out - now!
I’ve only ever had peripheral acquaintances with Access but this sounds right, from shuddering IT folk talk about Access line-of-biz apps. It’s an early stage 80/20 tool, which can do “good things” for a clever user. It’s seductive because it looks more serious than using Excel to “do database”.
That’s the 80% part, sucking you in.
The 20% part which will do 1000% of the pain, comes later, after it graduates to becoming something the business relies on. It was never meant to be multiuser. Since it was typically hacked together by a non-programmer “on their spare time”, no one is going to believe how much time and resources it takes to convert the app to something more solid so they’ll double down on keeping it.
I've seen an Access DB where queries were nested so deep it took >20 minutes for the data to load (which multiple people would have to do multiple times per day).
They'd open the database and then go and make a cuppa while it loaded. It was a running joke in the office.
Presumably this waiting period had got longer and longer over the years, and even when sat at 20 minutes, nobody had thought "this is becoming a problem ... maybe we should do something?!".
It has no place in business at all - not now, not ever. It was designed for granny to store a list of local taxi services (max 5 or 6 - and she should probably keep a paper copy).
Were you to line up all Microsoft products in order of shitness,, Access would be sitting in third place, beaming at the fact it scraped bronze, thankful Windows ME and FrontPage grabbed all the headlines picking up gold and silver. However, unlike those products, it still lingers around, stinking out business globally with its fetid, wretched, awfulness.
Thank God it only exists on Widows.
I had one which started out as one of the engineers setting up an equipment database for plant maintenance and replacement purposes.
Somebody else got hold of it and and decided to add a supplier list, purchasing data, then someone else added cost data and it grew like topsy.
After a few years it was almost completely unusable.
It took a lot of work to untangle the unholy mess when the company went over to SAP.
It's entirely file based
Actually, it's record based. Using the database primitives provided by the operating system.
The database primitives provided by the operating system date back to DOS SHARE and SMB, pre-date Windows authentication, expect per-table files, and don't provide for record-level authentication, so (in order to get a single-file database) Access still creates a whole system of app-level authentication.
Microsoft had the idea of upgrading the Operating System Database Primitives after Win2K, but the project failed, and MS SQL Server was making too much money anyway, and MS development became very badly siloed, and Access development languished, and usability and reliability and compatibility went backwards.
You're not wrong, but the framing of your argument (in quoting the OP) IS wrong.
Access uses a file based storage system (which is what was highlighted - the issues are inherent in file based databases, which is why they died a death, except Access, and became server based systems instead).
In addition to being a file based storage system, it is also a record based (relational) database.
Both statements are correct and true, but one does not oppose the other, which is what you've suggested by quoting "file based" followed by "actually....".
This might be the most stupid thing I've ever read on here (which is really saying something!).
You do appreciate that the way file data is stored and accessed on the computer system is completely different to how data is organised within a database, right?
File based storage - the way the database is stored and accessed on a computer system (aka: as opposed to client/server - which is infinitely better for fairly obvious reasons to anyone with a brain).
Record based system - the way data is organised WITHIN the database.
You can have a record based system, stored on file based storage (with the problems inherent stated above), or, you can have a record based system stored on the client/server model. It's not rocket science.
Let me guess; you're a DBA and nobody ever trusted you with system access?
This post has been deleted by its author
At first it seems good, but i gre into hating it with passion.
Now I have to use it because if you want to import data into sql server, expecially from Excel (SIGH) the only way is to import into access first and send it to sql through an odbc connection.
And then clean up the shit, but at least serial numbers are not written like like 1.56*e^7.
bulk load/ bcp work just fine.
From the management studio there are some handy functions like "Import flat file" (occasionally works) and "Importa data" which is more flexible but basically never works ( it was working at the time of SQL server 2000).
It's not for production workloads, but handy for one-off imports which are often needed on new projects.
"If you haven't migrated off Access, do it now. We will be adding AI and fucking up the system you've used every day for 20 years. Normal behaviour will include, but not limited to:
Incorrect Information Read / Write.
Unhelpful Prompts every 30 seconds.
Increases in memory, disk space usage and power of up to 500%
Increased user frustration.
Unsecured, confidential plain text information appearing on the open web.
File deletion
Complete system wipes"
There will be no opt-out available.
I actually had the opposite problem back in the day. I started using Linux in 1993... I was running 800x600 in 256 colors, or 1024x768 1-bit (the card was actually running 4-bit -- 16 collor -- mode, but this was unheard of in UNIX so if you actually went to run any software in 16 color mode it almost always immeidately crashed. So XFree86 allowed presenting 16 color modes as monochrome.)
But by the late 1980s, it was completely routine for these UNIX workstations to have 21" CRT running at 1280x1024 or even 1600x1200. They figured if you were already spaffing out 5-10K for a system, of course you'd spend like $500-1000 for a large high-resolution monitor. My first year or two of using Linux, when I did fire up X to run some application, probably half the time it woudn't even fit on the screen. So ironically the early work on Linux GUI applications amounted to trimming them down so they could run on the low-res screens typical of the PC.
As for Access... for those who really haven't used it... it's like a form builder on top of a sqlite-style thing (in terms of the Access 'database' just being a single file that it read and wrote to directly) but Microsoft Jet had none of the speed, stability, robustness, error recovery, or crash recovery of sqlite. They did apparently replace this with "ACE" in 2007 (if you have an .mdb file it's JET, if you have .accdb it's ACE). Which I assume is better in some way than JET? I don't know. Basically it was quick and easy to rig a form and get something up and running; it was really not very good to be honest but (as you see in the comments) the same places that abuse Excel spreadsheets for things would almost invariably have been using Access at some point if not still.
That 22" form limit limitation is really weird. Given (in the UNIX world at least) 21" monitors were already common, having a limit of 22" doesn't seem that forward thinking. I'm also just not sure why there'd be a size limit at all. I bet it's something weird like they used some arbitrary units and that turned out to be 32768 units (limit of a signed 16-bit integer) or some odd thing like that. I'll just say... a) Better late than never I guess? b) I'd hate to see what someone is coming up with that really needs ore than a 22" wide form. That's going to be one heinous Access application LOL.
Integer is exactly that. In the 90s Microsoft was measuring things for print still, so everything was in inches/centimetres. In terms of screen space, there are something like 1440 'twips' per inch. These twips were the standard for screen sizing. So when a size was needed for Access forms, when CRTs were still low resolutions like 1024 pixels wide, they worked out that an integer would give 32767 twips, about 22.5 inches, equating to about 2000 pixels. Access has survived to now because that's still larger than HD, but it was becoming a problem quite a few years ago. Now there are far larger resolutions than HD and it just can't work to those sizes properly.
This is all academic of course, because Access's entire GUI needs an overhaul if it is to be able to properly size to variable resolutions.
"As for Access... for those who really haven't used it... it's like a form builder on top of a sqlite-style thing (in terms of the Access 'database' just being a single file that it read and wrote to directly) but Microsoft Jet had none of the speed, stability, robustness, error recovery, or crash recovery of sqlite."
SQLite is from 2000 and Access from 1992. One would expect nothing less from SQLite.
Access has the GUI and GUI editor built-in. With SQLite you still need a separate application to use it as a back-end, so these are not really comparable products.
"But by the late 1980s, it was completely routine for these UNIX workstations to have 21" CRT running at 1280x1024 or even 1600x1200. They figured if you were already spaffing out 5-10K for a system, of course you'd spend like $500-1000 for a large high-resolution monitor."
In the late 1980s a 19" 1280x1024 monitor would easily cost $2000 - $3000. Plain 14" VGA was something like 300-400 dollars.
No good shall come from this! For it is written - on the Tablets of Gates, that "...no man may extendeth beyond what is right & good: 22 finger widths of his digits" [an archaic measure, equating to just under 22 inches]
I fully expect plagues of locusts; the dead rising from the grave; cats & dogs - living together...
Like any tool, Access can be diabolical. But in my experience using it as a front end for data entry and even basic reports it's actually fine. Very easy to use, low barrier to entry. Plug in a solid backend DB (MySQL, SQL Server) and it's robust and efficient for SMB use.
Much rather deal with the above than some of the horrendous Excel sheets I've had to try and troubleshoot over the years.
Exactly. 99% of the issues with Access are entirely down to the default Jet (and later Ace) DB engines. I'm pretty sure they were only ever really intended for prototyping.
You were probably "supposed" to move to MS SQL, but it supports basically anything.
The problems arise when the business throws the prototype into full production - as is very, very common.
These days the same thing happens even more often with Excel, which does not have an upgrade path at all.
Access predates all this modern open source stuff like MySQL, MariaDB etc. You were *supposed* to use Access, and in the absence of anything else, it's what you did.
When Access was all the rage (late 90s) there were no real viable alternatives. You had this database app (lication - we didn't call them apps) bundled with your word processor and spreadsheet - why wouldn't you? These were the days when you sent half the office off to a local hotel for the day (lunch provided!) for a beginners training session with each of the Office programmes and they came back empowered, enthusiastic and ready to wreak well-intentioned carnage with Excel and its big brother.
And, tbf, as others have previously stated, it was fine, at least until it wasn't. As a quick prototyper or a system for a small workgroup, it could cope. It's when it grew, and grew and grew that you had problems. For a while, you could get by by separating the data from the front end (call in a proper developer on a day rate!) but ultimately record locking and file security were waiting to bite you, maybe not today, maybe not tomorrow, but some day.
I switched my lovingly created classic ASP-based intranet app from Access to MySQL in a weekend as I recall. As soon as there was a viable alternative, I fled to a "proper" database. But in the 90s? Access was king.
Access was the shopkeeper database tool. For small businesses, a handful of people. There was Ashton Tate DBase, Foxpro, Clipper and all of those similar but Access was the one that was bundled in with the software that people already had on their pirate unlicensed copy of Office so that's what they used.
If you were going to use a proper RDBMS backend in those days then you might as well ignore Access and just use VB or Delphi (or Paradox) for the front end. People didn't really understand the schema designer anyway, they were usually monster flat files without normalisation analogous to spreadsheets. But actually things like the Ingres derivatives like Sybase were a little bit more techy and mysterious and also harder to acquire for free.
OMG the flashbacks!
Back in the day I had (or so I thought) a nice little gig as a freelancer for an upmarket consultancy taking the home-brewed Access databases they had developed and porting them to MySQL. Found some nice freeware conversion scripts that did a lot of the grunt work, mixed in some scripts of my own to parse various things and job's a goodun.
First three jobs or so went like a dream, scripts did 95% of the work, thought I had it nailed, quoted for the next one. That's when I found out that Access did something that MySQL couldn't. I've applied the mind bleach to the whole sorry episode but it was something like being able to use a query as a variable inside another query. Cue working right across Christmas and New Year disassembling and refactoring horrendous wizard-generated queries by hand.
We live and learn.
And because of using access as a front end tool (or just to run queries on production dbs because the management studio was 'too hard') I've been forced to use float data type instead of decimal in a SQL server db because apparently Access couldn't handle them correctly.
How do you cut a piece of metal 1.4999999999999999998 meters long?
I still have to use Access as my main development tool as I'm business side and the IT department have a thick brick wall between users and development software.
So this is welcome news. However, there is still the pressing problem of getting the 64 bit VBA fully 100% in line with what the 32 bit VBA could do. There are still too many bugs and missing features, and all of them, including undocumented features, need to be in 64 bit in order that everything works (doesn't work!) as needed. Once that's done then finally 32 bit Office can be junked, something that IT departments have wanted for years.
Access stores co-ordinates in 1/1440th of an inch (of course) and the maximum co-ordinate it could use was 32767 of those.
If you know the resolution and ppi you know the monitor size in inches. Only it was probably a lie because more often than not Windows used to assume 96 ppi so the whole idea of device-independent form coordinates fell flat on its arse.
While Access *sucks* when you use it's inbuilt DBMS, if you outsource that to an external DBMS and only use Access as a frontend it is acceptable and - dare I say it - dependable and reliable. If very slow.
Unfortunately we have a system built around this arrangement that we can't afford to replace.
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.
...is "one of the most highly requested enhancements from the Access community and a top-voted request on the Access feedback forum."
With the single most requested enhancement being to cull Access for good.
If you disagree, bear in mind, I've been traumatised by this tool and its abuse and hate it with irrational passion.
"The 640 x 480 pixels of the Video Graphics Array (VGA) standard might be scoffed at by modern engineers"
And yet, fire up an emulation/virtualisation environment running an older system with that sort of resolution, and more often than not it *won't* feel anything like as cramped as the numbers suggest - yes, we have larger screens running at higher resolutions, but as with memory, drive space and CPU cycles, the software of today has simply bloated out to fill the available capacity whilst offering little in return.
When you *had* to squeeze your UI into 640x480 (or even lower if we're going a bit further back in time), you made damn sure that every last pixel was put to good use. Blank space was wasted space, so there was little or no thought given to making the UI look like a graphic designers dream - function over form every single time.
I think back to how much work I was able to get done on a single 14" screen running Workbench at 640x256, and I think about how much time these days I spend juggling windows across dual 24" 1920x1200 displays, and I realise just how much I miss those good old days of personal computing...
1 - Do NOT install an Oracle product unless you're willing to become a millionaire (of course, you would have to have started as a billionaire - otherwise, YMMV )
2 - Do NOT install your office suite with Access. No quick and dirty, no proof of concept, no installs, no screen mockups. NO. I'd nearly say the same about Excel, but even I can't BoFH my way past that many bean counters. But you can nuke thier macros on security grounds.
There is probably a third rule but after ensuring the above 2 apply, everything else is pretty easy.
I think most complaints about Access were fundamentally about its misuse. And responses to this misuse then consisted of condemning the tools entirely rather than controlling the misuse.
Access is primarily supposed to be an office productivity and automation tool, where the databases are either for personal use, or (if multi-user) remain under the continued supervision of their original maker. It is not supposed to be the foundation for a piece of independently distributable software, nor is a particular file supposed to be maintained by teams of (or multiple generations of) developers.
Lots of businesses got shocks when they became reliant on these tools then allowed the maker to casually leave or retire, yet assumed a significant edifice of complexity would be easily taken up next by a poorly paid apprentice. The reality is that Access developers were often key managers with an enormous amount of job complexity and business operational knowledge concentrated in them.
The other issue is that businesses that grew in scale having started with Access, often did not limit the complexity of the development in Access or shift to using both new staff and/or different tools more suited to the complexity and robustness of the larger scale. This meant Access was used well beyond its suitability, or Access developers were pushed well beyond their competence and experience.
Nowadays Access is a very dated technology. It's typically possible to press Excel into doing most of what only Access could once (in the mid-90s) have done effectively, and in many regards Excel is now vastly more powerful and flexible than Access.
My first job out of uni in the early 1990's, I was hired to write a CRM system for an Oxford college covering staff, students, visitors, conference attendees, etc - using Access 2.0. Yes, it even included record-level data ownership, DDE connections to Word for letter writing (donations xmas cards, etc), etc.
I forget how many tables it was, but it had 5-7 concurrent users from a shared drive (DecNET / Pathworks on an Alpha running VMS).
6 months after I left, the inevitable performance issues started and they paid a consultancy to "redevelop" the app to use an MSSQL backend. Once they got access to the code it took them 3 hours to find and change the connection strings and mke them point to the new SQL. The data migration took a weekend and the users forms etc were unchaged.
I enjoyed that job - and Access worked really well for quite a high-end salesforce-like contact mnagement system.
Moved into security, not DBA - but anytime someone tries to diss Access, i know it tell me more about the person talkng than about the product...
