Yes, Microsoft Access was a recalcitrant beast, but the first step is to turn the computer on On the fourth day of Christmas, the bork gods sent to me: one dead DB, petty angry user, flightless Windows signage, and a server they said had ceased to be. Welcome to the Twelve Borks of Christmas (12BoC): a collection of Register reader stories of amusing and frustrating tech sightings over the festive period. Today's …
And what would that have been? No matter what database server you use, the machine running it has to be turned on. There are two good solutions to this: a server in a place where you can't easily turn it off and a redundant server which can withstand one being turned off. Either approach costs money and causes extra complication. A standard small business has tons of single points of failure. The network connection to the office might get severed. Power to the office might fail. A water leak could force an evacuation. Someone might forget the key to unlock it while the person with the other key is off on holiday. Each and every one of these will borke the workflow more than a database going down, but somehow the database needs to be more resilient anyway?
Yes. That's true. Having a separate machine for client and server in a time where machines were expensive would have cost money. Given that the client and server could apparently run fine in shared resources, all that needed to change was that people needed to remember not to turn off the box. The original comment complained about a single point of failure, which this wasn't really. The source of the problem was an operational decision, not an architectural one.
The problem with the original complaint is that it is a textbook solution which doesn't look at any of the specifics. A single point of failure is a negative in a system design, but so is limited time, limited money, limited disk, etc. These things are only preventable if more resources are thrown at the project. Singling out SPOF as the thing which must never be allowed makes it seem as if the person who created the database made an obvious mistake, but the compromise was undoubtedly chosen because the available resources required one. Single points of failure are sometimes necessary, and treating them as anathema is only possible if you're willing to always spend ten times as much to eliminate as many as I can point out, and I can point out a lot.
I have one that spans the 90s up to literally last month. Our students' records system was developed in Access with a Visual Basic front end in the 90s, by a team of three developers, without any adult supervision, i.e. it was a complex mess of forms and reports with a very disorganized set of tables and a user interface that followed the Helen Keller School of Usability. Nonetheless, it worked, mainly because it ran in a single machine (none of that fancy pants multiuser capabilities), and the secretary that operated it knew all the functions and limitations of it.
During the 2010s the three original developers retired. Before that whenever we asked for changes they created the new tables, forms, and reports and crammed yet another button in the user interface. Whenever we suggested a major overhaul they just resisted because "the one we have still worked" but just in case they took several courses on cutting-edge technologies such as ColdFusion.
I proposed a new system, without too many complex frameworks and interfaces, just to have a working system for the next 15-20 years, but nobody (especially the Supreme Head of IT at the time) saw the point in wasting time developing a software view as redundant. Since my suggestion required to copy the data for importing into a proper database, then throwing away all code, it was less than welcome.
Now the three of them retired, and the Supreme Head of IT too. The original VB+Access system still works but no one can write any additional report or form for it. The Powers That Be are looking for "open source, no-cost, ready to use" variants (no budget for this). I promised myself I won't get involved in this.
-- fades those memories.
Similarly, in the mid-Nineties the IT at the utility at which I worked informed my work section that, as we were leaving Lotus 1-2-3 behind and slipping into Microsoft's bed, they would not be building an interface for our lab and field data. Ya, uh-huh, hello Access. In the hands of motivated but ignorant industrial operators.
Oh, we knew the Access thing we spawned was a mess. Every few years my manager would send out a Request For Proposal to purchase a professionally-programmed package, and every time the price tag sent the entire staff into black despair just short of mass suicide.
By the time I got my 30 years in, I had migrated a major area of data into an SQLite database with a .net front-end (may Cthulhu forgive me my many sins along the way), and the rest of the lab data had been shoehorned into a proprietary framework offered as a sideline by a chemical analysis company. It had to interface with the SQLite via a .csv export... See, I begin to shake even writing about it. The spaghetti architecture, the horror, the horror. Is this digital blood upon my hands??
I echo the advice of Will Godfrey: RETIRE! At once. Or find a position with a sensible firm.
I still get a request like that every now and then, and it never ceases to astonish me. You've been customizing a bit of software for 20 years, how can you possibly think to just randomly find a bit of free software somewhere that does exactly the same stuff? Or that re-applying the same 20 years of customizations to a bit of free software is somehow going to also be free?
To be more precise, you are free to modify it to suit your needs. Do you have a complete list of those needs? If so, I can give you an estimate of the cost of modifying the source to suit your needs. (Note that "modifying" might go as far as a total re-write from scratch of everything but the name of the executable. And I'll probably rename it, it if has to go that far.)
During the Nineties, I was a single point of failure, and I'd done it on purpose. They fire me, they'd lose the ability to use the database. When I retired, they hired a teenager. I'm not sure if they were sorry or not -- who knows the mind of a director -- but the web access became a lot more whitebread and hard to use.
I did something close once ... In late 1977 I managed to take down all the PDP10 kit at Stanford and Berkeley with a software upgrade. Effectively split the West coast ARPANet in half for a couple hours. Not fun having bigwigs from Moffett and NASA Ames screaming because they couldn't talk to JPL and Lockheed without going through MIT ...
The ability of the system to route around problems require someone to build the routes to be able to route a round the problem.
We had 3 ISDN Private Wire routes out of the building for our IT data centre heading in different directions and only discovered BT had decided to re-route two of them on the same trunk as the other a couple of hundred yards from the building when someone dug it up. I cant remember if we got a refund or not.
In the days of hand-massaged static routing tables, routing around problems connecting to government contract systems involved several committee meetings. In triplicate. With at least one trip across country.
Contrary to popular belief, TehIntraWebTubes was not designed to route around nuclear war. The .mil already had SLFCS and then MEECN for that kind of thing.
The only reason we had alternate routing in the early days of the 'net was because the hardware we were using was, to put it mildly, quite flaky.
For a day or two that wouldn't be much of a problem, at least for people like me[0] who grew up without The Internet; I can see the InstaBookTwitTokIoT crowd going[1] stark raving bonkers, and even more so when they discover that their sorrow-quenching food and/or drink has become sold out and can't be reordered because of no Internet.
[0] there's several weeks worth of books to be (re-)read, and that is with pausing only for eating and sleeping.
[1] well, several orders of magnitude more than they're now.
At least Access was (albeit marginally) better for those folks who tried to run their businesses on the back of Excel. Generally these came with a million macros that only the person who'd written it without any documentation knew how it ticked (and they'd left the company last year).
The local authority, in its beneficence, supplied us with a few PCs ( out of our existing budget of course) and didn't think in terms of how we'd use them, i.e. sharing case load data and templates. Or as the technically minded would call this - a server. In effect a bunch of standalone PCs on a simple network.
After about two years of nagging the new shiny IT educational dept. agreed to create a shared drive..And to be honest, pretty much all we needed, as long as people kept their own backups as well as the ones I made of the shared drive, because,well, it was a good thing to do. - they did in as much as no one trusted such complexity as a shared drive and still did most of the saving locally or on a floppy. None-the-less, we started to use standard templates and assessment materials and some people even saved to the shared drive, which meant we could get access to their stuff if they fell ill or whatever.
And then one day no one could get to the shared drive.
And no one knew why.
I was out of the office at the time, doing my main job the same as almost everyone else - which wasn't nursing the computers, especially now that there were proper professionals for that.
So when I got back a couple of hours later there were a few of the people who'd come in to do admin fuming, and several more being smug because they still kept their files locally (probably on floppy discs).
I went in to the room, had a quick look, went to the last computer in the row and turned it back on..
No one had ever explicitly told us that this was the machine being used as a shared drive - I don't think I'd even known myself, and since it wasn't needed that day, because there weren't many people on site, no one had turned it on.
At least it made the case for a proper server to be provided.....
In the late '70s there was a massive panic at SLAC for a similar thing, but it happened BEFORE the event came to pass. Seems a newly installed bean-counter-in-charge decided he could be a hero and massively save on the year's costs by powering down the entire campus over the solstice/xmas/newyear break. Including all the computers, and everything connected to the beam. Rumo(u)r had it that Jimmy Carter himself called and bitched him out over the bone-headed idea.
My wife once worked for a Housing Association where they had the "server" PC in the head office in London with the regional offices just having "client" PCs and a printers ... and the printers, though in thhe regional offices, were accessed via a conenction to a printer on the server. So on the days where there were "network issues" they were sat in the office able to do most of their work on their PCs - but couldn't print anything on the printer at the other side of the office as the print job needed a round trip to London to get there! I'm sure someone thought htis was a good idea at some point.
Reminds me of an interview that I went to with what was, in those days, a very large brewery; but nowadays is just a very large hotel chain, coffee shop chain and pubco.
The interviewer, an IT department manager, was an hour late, seemed harassed and had egg stains on his tie.
He explained that they had two large machines, midis or minis, I can’t recall, in the same “suite” and that they communicated using modems over the telephone network. Something to do with synchronisation or whatever.
I tried to suggest that they could use a LAN or, failing that, at least install a couple of modreps.
My interviewer did not understand a word.
Then one of his team leaders burst in and asked for permission to use the departmental car as they had to drive to Bristol on some emergency call out.
I lost interest at that point and wasn’t asked back anyway... thank $deity.
You've just reminded me of a job interview I had for working in a fruit machine company. It was all going well until I suggested simulating the machines to ensure they were fully random and then realised from the look on the interviewers face that perhaps these sequences people jabbered about allowing them to win on supposedly random machines were in fact real after all! I let myself out.
Curious about this, back in the 90s I actually bought an old 2ndhand fruit machine. It was mechanical, but had a digital controller.
After examining the innards and finding the controls, trawling for documentation and so on, I found a number of things -
* How to set the percentage return, that the machine would cheat in order to attain
* The big cheat switch that would NEVER allow you to win if the money inside the box was running low
* How it always skimmed off money into a lower cashbox to ensure that it would never, never pay our more than about 80% of takings
It showed that it is absolutely impossible to lose money with these -- if you own the machine. Otherwise, you're a sucker waiting to be fleeced.
The fun bit was setting the return to 80% (the highest it would go) and then playing to *lose* (holding the wrong reels, gambling a win until it failed, etc). After a while, the machine would get desperate that the return rate was too *low* and would eventually start giving a chain of natural jackpots.
The first of these is not a "cheat". It's standard that all gaming devices have a percentage return. I'm only surprised that it's as high as 80%. I think at one time there was a minimum payout level controlled by the UK Gaming authorities, but their website states that there isn't now (a result of deregulation maybe). The figure has to be stated though.
This is their web page on the matter.
https://www.gamblingcommission.gov.uk/for-the-public/Safer-gambling/Consumer-guides/Machines-Fruit-machines-FOBTs/Gaming-machine-payouts-RTP.aspx
In effect you are gambling against the other mugs punters, not the machine operators, to get the winnings out.
The other component " The big cheat switch that would NEVER allow you to win if the money inside the box was running low" did surprise me - but then the same device/controller/firmware may be sold into less regulated markets, I guess. Or maybe it's one of those fiddles that fell between the cracks in the regs.
*In my youth I worked in a casino for a few months, till they had sense and got rid of me. I was rubbish when it came to carefully recording figures on a paper spreadsheet ( or a digital one for that matter).
"In effect you are gambling against the other mugs punters, not the machine operators, to get the winnings out."
Absolutely untrue. The only people who are guaranteed to win are the House. Everybody else is a sucker who *might* get lucky, but the odds are always against it for any given sucker.
That's what that says.
The house (re)pays a percentage as winnings. The house keeps the rest. When you win you aren't beating the house's odds. You are beating the other mug punters to the share that the house allows out. The more you play the more the house skims off, which is why the fixed odds machines in betting shops work so fast - the money mill has to keep rolling. It's why casino dealers work so fast, spin and rake, spin and rake.
That's why casinos and bookmakers love big winners (even when the horsey press will talk about the bookmakers taking a beating or some such nonsense)- because they know that a) the punter will probably give it all back, that b) they've kept their edge ( unless they're very small and haven't laid the risk off) and c) it'll encourage other mug punters to throw cash their way
You never beat the house on a slot machine because the house always keeps its percentage edge. The most you can hope for is that the other mug punters will have filled up the machine ahead of you.
That's incorrect. You're assuming it's skill-less to play, but in fact you can (learn to) read the state of the machine cheaply enough to turn a small profit on average - walking away a quid down when it isn't paying out, and extracting a few quid when it is.
One sure--thing win is if you watch a mug fill a machine, and then it sits unused for a few minutes - playing then is going to win, and with practice, you can tell if it's in that state by the cues the machine gives, even if you weren't there to see the history.
Amdahl had a largish printing facility just off Central Expressway in Sunnyvale (Cupertino?) in the 1980s. Virtually every mainframe print-job generated within the company, world-wide, was printed at said facility, and then next-dayed to whatever office had requested the print job. They had several gawdawfulfast channel attached printers, and a fleet of trucks delivering & sending out paper. Was awesome to watch in full-swing, if you had adequate ear protection.
However ... it sounded daft then, and still sounds daft now.
Let's face it, what has actually fundamentally changed between the problem described in this story and every story of cloud bork reported every day this past year? Still the same issue : computer unavailable via network. Whether that computer is an ancient 386 in Ken's office or on a rack in an Azure datacentre is irrelevant when you find that remote access to your files has ceased. Although those of us who actually had to endure the horrors of Windows for Workgroups and Netware back in the mists of time probably appreciate it better than the modern folk who take it as read that everything automatically connects to networks and starts working instantly. Most of the time.
Quality is a subset of quantity. Only a few folks have the ability and inclination to actually learn how these contraptions work. The more people who get the training, the more likely any one office sub-set will have an employee with a few useful clues. Bell shaped curve, innit.
At least someone had enough sense to use a database even if it is Access. My real problem with Access is not the program but that the Rejects of Redmond oversold its capabilities. If used correctly it was perfectly good solution. But like its stablemate, Excel, it tended to be pushed to places it should not go.
Access could go to good places if you connected into SQLServer rather than the JET thingy - indeed plugging it into MySQL for development was my favourite time saver. Discovering VB had gone OO just before I wandered off leaving MS to their own devices makes me wonder what I could do with it today.
While working as a "tech grunt" (mostly pulling cables and plugging in machines that "worked perfectly well yesterday") for a University, I was asked to wire up a recently remodeled room for a research group headed by a Very Important Professor. He wanted the typical "sea of desks" with a terminal each, but I wondered how the data lines were to get to the desks in mid-room. "It's already wired up, see?", pointing to the power outlets recessed in to the poured-concrete floor. When I asked again "what about the data cables?", he seemed not to understand the question. Early 1970's so, no, WiFi was not an available solution, even if WiFi ADM terminals had been available.
Same job, different person whose sky was a different color, I got angry call from outraged grad student that the scope we had sent out for calibration would now not power up. I knew better than to ask if it was plugged in, so headed for his lab, where the first thing he said was along the lines of "you can see it's plugged in", and indeed the scope was plugged in to the power strip on the cart, which was also plugged into itself Ouroboros style. I guess if I had been braver (and more willing to find another job) I might have asked if he had the budget and lab-safety permission to slap a generator on the bottom shelf of the cart. Instead I plugged the power strip into a real outlet and powered on the scope. The E.E. grad student was mystified, albeit not visibly grateful.
"I wondered how the data lines were to get to the desks in mid-room"
Cable drop from the ceiling into the center of each row. Done it hundreds of times. Back then, you could even have gotten away with the cables dangling from the ceiling supports with a Ty-Rap. Ugly and not very resilient, but that pretty much describes classroom computing in the '70s.
... it won't corrupt your data. In the early days of Access and the Microsoft Jet Engine, I was called in to look at the problem of Access periodically deleting a series of records when the users were doing editing. The users were able to repeatedly demonstrate the series of actions that would cause this to occur. My expertise was not in databases (especially Access), but in hardware problems and configuring DOS and Windows 3.1x, including the networking. Where I worked, I developed a process where I could test for hard-drive store/read issues (necessitated by a hard-drive manufacturer not testing a new model drive that would periodically repeat a word in the middle of a track read, shifting the remainder of the data). The procedure was easily modified for testing reliability of network communication. Their network tested fine. My conclusion was that the issue was solely with Access and the Jet engine and I had no useful guidance for them. My understanding this was a common complaint of Access users, but Microsoft continued to deny there was any problem. I seem to recall reading an article a few years later that Microsoft acknowledged there was a bug that would cause this behavior, but it was a couple years later before they had a fix. I personally have never had a problem with any Microsoft database at home or where I now work - I just won't use one.
Built tons of stuff on Access.
totally fine and pretty solid for <15 users
Pros
1) Requires 15% of dev man hours compared to full stack web apps ( I do those too)
2) changes at run time without any compiling for forms, db, queries and reports - makes to super agile evolution
3) very short learning curve for full stack
I'm glad that this article didn't take the turn I was expecting. Seems like "real IT guys" like to say that Access is garbage. Quite the contrary. I love Access. I've been working with it and teaching it since 1994. But yeah, you gotta turn on the "server" PC for a linked database. That's funny. I had a similar story from back in my IT support days. Customer couldn't figure out why her PC would randomly restart. Turns out her foot kept kicking the power strip. :P
My friend Dave worked in IT as a systems analyst. He helped to design and build an Access application for "Marketing". They loved the application, and they loved Dave so much that they offered him a job. So he moved to "Marketing" and set about expanding the application and the underlying database, all still in Access.
*
And "Marketing" loved the application so, so much......................until the application reached the Access database size limits. Oh dear!! So Dave went back to the IT folk and told his story, and begged for a FAST conversion to a real database. IT said "Sorry.....we're busy. Come back next year".
*
"Marketing" were p*ssed.....Dave was fired. Hero to zero......all because of a huge "success" with Access.
This happened to me except the PC was in the server room, hooked up to the server room UPS etc.
This was back in the mid 90's when enterprises were just dipping their toes into hosting their own website.
Hired to do create this enterprises first website, I had to cobble together one from typical office PC gear left over from previous equipment refreshes.
For some reason the IT techs thought because they did not install it or manage it, they did not have to keep it running.
The server room had a minor flooding issue having to do with cracks in the foundation so there was major disruption as contractors came in and dug up concrete and replaced it. The IT techs had to rewire the whole room as stuff had to me moved around to give access to the parts of the floor needing work.
I get a frantic call that the DB on that PC is not responding. It turns out that when the Techs rewired, that PC was not their responsibility, so it was not reconnected after it was physically move. At the time, they were all out at a remote location for some emergency, so I had to figure out where to reconnect it.
My guess at where to connect it worked, but I got a lecture later that I should have reconnected it at a different spot than where I did.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
