I have a lead that insists on transforming our database from Excel to Access, and I’m about to retire just to not have to deal with it. In my old group (2011), only one person knew the program. Now this guy comes into our group and within 6 months steamrolled our entire database into Access, but it’s not a database I have to deal with often, so I let it be. But now he’s set on taking my main spreadsheet and migrating it to Access as well. Our company, one of the largest in the world, does not support Access, so I’d have to track down training online. I’d rather say Fuckit and retire. But I’m curious-how obsolete is Access?
Note: The most recent stable release of Office 365 1904 was 15 days ago. That doesn’t make it obsolete.
While a lot of people do limited DBs in Excel, if you have anything interesting you need to use a DB program.
Is Access the right DB program for the job? Probably not. But it might be a good choice in certain circumstances. If it’s not your choice then you either live it or you don’t. If you don’t think you can handle Excel you presumably can’t handle other DB programs either.
So why is Excel in particular an issue for you?
Your company, one of the largest in the world, maintains databases in Excel spreadsheets?
Access might or might not be the best choice for your database needs, but it’s certainly better database software than Excel, because Excel is not database software. You can kludge a spreadsheet into being used like a database, but it’ll be clumsy and slow.
Repeat after me:
“Excel is not the solution. Excel is the problem!”
Not even close, Excel is like working with hand tools and access gives you power tools.
Seeking a better tool for some data juggling and reporting I dug into access, I wish I had done it years before. If you already own solid excel skills You can get a handle on the fundamentals of access in a few weeks, once you own them, the concepts apply to pretty much any database software out there. Go get yourself a copy of access for dummies and get going, you wont regret it.
I worked for a company that is pretty much a household name. much of their supply chain was excel spreadsheets emailed around until about 2003 and 90% of the analysis/reporting work is still excel and access to this day.
Based on a previous situation, I would be leery of converting your databases to ones that are homemade by this one co-worker. What is going to happen when he leaves the company and something needs to be changed or updated in the database? Is the thing documented? One department here had an Access database that was similarly homemade by a long-gone employee in an older version of Access. When their computers were to be upgraded to a new version of Windows and a new version of Office, they found that the database wouldn’t run in the newer Access version without some work needing to be done. And of course no one knew anything about the database. I think they hired the guy to come in for a couple of hours or days to help out.
Official policy here is that all software needs to have a document specifying how it’s supported, whether that’s by an in-house team, vendor or whatever.
My current client is one of those really big companies nobody has heard of; their products aren’t sold directly to customers but all of us have used them.
Of four factories in the current rollout, one has a jungle of macro’d excels that would make much more sense as a database, but hey, the lab manager is the guy who made it and who maintains it. Nobody else has the foggiest idea how to untangle that thing. Another factory has their lab info in word but they’re organized enough they expect to be able to put it in an uploadable format within a month; they’re taking advantage of the project to clean up some stuff they’d been saying “we ought’a clean that up…” “you got time? 'cos I agree but I don’t have any” “… no…”. Yet another has their lab info in six (6) different places, including excel, word, paper and two (2) different bespoke databases. And another has their information in a mixture of paper (word printouts but the originals aren’t accessible, as nobody has access to that sharepoint any more) and a bespoke database where the lab manager and another person know how to update data but nobody knows how to get extracts.
Right now I’m thinking lovingly of former clients who used a single method to keep their data. Note that the one factory that’s doing ok is the one which does use a single method, even if word isn’t exactly database-conversion friendly.
Access isn’t obsolete but Microsoft treats it like the ugly stepchild and puts most of the emphasis on Microsoft SQL.
I migrated my primitive excel database processes to Microsoft SQL about 12 years ago but did so because I realized that my data needs were going to eventually exceed the capabilities of Access.
Microsoft has tried to lure more of the Excel users toward SQL via DAX and Powerpivot development.
I don’t know how to use Access but in my opinion I think its adequate for small database usage. While it’s not obsolete I would have some concerns that Microsoft would someday make a hard push to get rid of it.
I know everyone likes to wig out when someone uses the words “database” and “Excel” together, but keep in mind that many people use “database” to simply mean a file with a bunch of data in it (in rows).
We keep plenty of little “databases” in Excel files for several reasons:
- Everyone has Excel. Many (most?) people do not have Access
- Everyone has a basic understanding of how to use Excel. It is much more user friendly with very little training.
- There are no legitimate benefits of moving them Access. I am sure Access can do all sorts of wonderful things, but we don’t need those things.
You can use it, among other ways, in “Microsoft SQL” mode. I normally use it with the visual editor as much as I can. I don’t really use it to manage databases: I use it to go from a single data-preparation Excel to a collection of data-loading txts (the most complicated conversion I’ve done got 32 txts out of a single starting sheet; the biggest one was 12 files but with a starting sheet over a quarter million lines long). Using a better, bigger database program for that seems like overkill. I think I lost my Office 2016 license when my previous computer had a stroke, so for the current project I’m going to use LibreOffice’s cousin of Access (even less powerful than Access, but enough for my needs).
I’d bet they all do. The Department in Charge of Some Things identifies a need to keep some records electronically. They could put in a request to Corporate IT, but that will eat a large chunk of budget, and the development - due to competing priorities - won’t been done until Q3 of the next-but-one financial year, or they could get the “good with Excel guy” to knock something up right away.
And in ten years time, it turns out that a small but important part of the workflow of the entire corporation is a series of giant spreadsheets that are held together by glue and paperclips. Spreadsheets that IT doesn’t even know exist.
Excel is great for a “database” that consists of a single table (and isn’t too big).
Access is great for smaller relational databases where you want to throw a quick user interface on top of it. With the wizards or some basic programming skills, you can quickly create simple forms and reports.
For anything bigger, with multiple users, enhanced security needs, or a more complex UI, a more robust database is better.
Access fits that niche in the middle very nicely. The problems happen when people use it for things outside of that. Without details of the data and usage, I have no idea if Access makes sense for you.
You could always migrate to Javelin, or Javelin Plus. As the ne plus ultra of mid-eighties data analysis software, it beat Excel in many categories. There are some windows compatibility issues, though.
Yup, here’s the problem, and it’s on me and my lack of knowledge about this language distinction. I know nothing about coding, which is what I think is what is being pointed out here. This lead comes from a coding background. But I’ve been in this business for forty years, and I never needed to know coding, and I’m not going to learn it this late in the game. I’m a design engineer, and I have to maintain a large spreadsheet of parts that the whole company uses. I’m planning on retiring soon, this is just nudging me into doing it sooner to avoid this. My experience is CAD, so I’ll keep up with that technology, not admin stuff. When I look for work after retiring, I won’t be selling any spreadsheet or database skills.
Access isn’t obsolete, it just hangs on for uses that don’t really require something better. Just like people would be surprised to learn how much stuff still gets done in Excel.
If this guy is converting your spreadsheet into an Access db, it’s not clear how that fucks you up or why you need any coding skills. If this guy knows how you use the spreadsheet, he should be building in whatever you need to do. And if things don’t work, the problem should get thrown back over the fence to him.
I agree if you’re close to retirement it’s a pain in the ass to learn anything different, even if it’s just what the fucking toolbar icons mean.
We had a program that started off as a demo someone wrote over the course of one night with a book on Visual Basic at his elbow. It was supposed to be for just a proof of concept demo, but it got deployed almost immediately and grew to become really important for various functions in the company (so that there were probably 5,000 or more instances of this thing among the perhaps 50,000 workstations in the enterprise). Of course no one else knew anything about the coding behind it and the guy who wrote the program left the company recently. So any day now, we’re going to switch to an established solution from Microsoft (something that’s built into Windows).
Okay; I’ll bite. By that definition, every text file is a database. This generalization renders the term term “database” meaningless. People who use “database” to mean “a file with data in it” are either grossly ill-informed or trying to make their system sound more sophisticated than it is. Sometimes it’s both.
[kvetch] Your argument is the one made by people who don’t understand what a database is. Using Excel worksheets as database tables is roughly analogous to driving a screw into the wall using a hammer. If you only know how to use a hammer, everything starts to look like a nail—including screws.
But those who drive screws with hammers shouldn’t be surprised that their “preferred” and “user-friendly” method makes carpenters cringe. And it’s so much worse when, upon being informed that a screwdriver would be the right choice, the hammer-wielder responds with, “I’m sure screwdrivers can do all sorts of wonderful things, but we don’t need those things.”
A screwdriver is the right tool for the job regardless of whether you know how to use one.
I’ve ventured into hyperbole here, but not by much. Your comment about how “everyone likes to wig out” implies that we who wig are merely making a semantic distinction between spreadsheets and databases, or at least that we somehow love to hate people who conflate databases and spreadsheets. We don’t. We—or someone like us—hate that we will have to clean up the spreadsheet-mess you’ve made. Maybe not today and maybe not tomorrow, but eventually. And it’s a little galling when the person who made the mess insists that there’s no mess there. [/kvetch]
Of course it’s convenient to store some bits of data in a spreadsheet. But it’s often a much worse idea than most people appreciate. Also, Access is a terrible database and also basically a dead end. It’s like the philips bit on a Swiss Army knife: under ideal circumstances, it’s almost adequate. Under any other circumstances, you want an actual screwdriver. And if you want to drive a screw but don’t know how to use a screwdriver, maybe ask a carpenter.
Hire me, and I’ll put your system in FileMaker instead. Far superior to Access. (and to Excel, which is not a database environment any more than Word is a graphics design studio).