Earlier quoted context omitted.
I got started using Access 2, so I'm older...
Learned 3NF in an Access 2 class, so I might be older... =)
Dbase3 and Clipper here.
Microsoft Access: The Database Software That Won't Die
91–100 of 365 posts
Re: Microsoft Access: The Database Software That Won't Die
#92Earlier quoted context omitted.
I don't disagree, but isn't it a sign of much deeper issues if this "Shadow IT" land exists at your company in the first place? Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Are they under-staffed? Neck-deep in spaghetti code? Lacking business knowledge and the opportunity to acquire it? Bottle-necked by a lack of business analysts or testers? I he…
Sometimes it is budget or just needing someone to drive it through a heavy process. It is also not always worth it if you cannot show a real business case. The thing might help you and it might be worth it if you hack something together yourself but if IT is suppose to build something that is available, has support, has disaster recovery, is patched etc. it might no longer be easy to find the business case for it.
Exactly, to get professional IT resources you need to demonstrate a business case, go through many decision boards and budget allocations, defend it for months, and be ready to be pointed out if it doesn't reach its promises.
So in the end people hack it in Excel or Access. No need to ask permission, no budget issues, no blame if it's not great.
Re: Microsoft Access: The Database Software That Won't Die
#93I cut my teeth on dBase II back in the day, and built my first consulting and development company on the back of that, then moving on to Clipper, FoxPro and Clarion and other tools over time. I always managed to skirt around Access whenever it came up in client meetings ("Oh, we have this FREE database thingy that came with our word processing and spreadsheet tools - why don't you use that to write our stock control app??").
It has been many years since I have seen Access, and I thank the database gods for that. Nowadays I run an HR SaaS company, but just yesterday we landed the biggest contract of our fledgling company with THE biggest manufacturer in the UK of a certain household product. All the excitement was sucked out of me when they asked if they could integrate our cloud HR system with their internal job costing & time sheet database... which is written in Access!
Re: Microsoft Access: The Database Software That Won't Die
#94The reason that both Access and Excel use is so prevalent in corporate “shadow IT” land is because there are many parts of the business that have problems for which only a negative or marginal business-case can be made for IT to solve it (given the “get out of bed” costs of most IT departments). It’s a barrier-to-entry problem. Excel and Access are cheap enough and fly under the corporate IT radar (no involvement nee…
I don't disagree, but isn't it a sign of much deeper issues if this "Shadow IT" land exists at your company in the first place? Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Are they under-staffed? Neck-deep in spaghetti code? Lacking business knowledge and the opportunity to acquire it? Bottle-necked by a lack of business analysts or testers? I he…
The problem is most of the people writing code in Access (or monstrous Excel macros or in apps like MatLab etc) are not trained programmers. I think the article sums it up well by using "power user" to describe them - technical people with no formal programming training. Think Engineers (the non software kind), Accountants, Plant Technicians these kinds of people.
In my org (I'm an Engineer at a manufacturing plant) a long time ago someone senior made the decision our company was not in business of hiring programmers so any coding is done by contractors.
So yes people have implemented things (Engineering models for example) in MatLab, or Access, or as an Excel spreadsheet etc as "prototypes" ostensibly intended to be rewritten by a real programmer. At some point these models invariably find their way into production environment and suddenly you have some kind of mission critical thing written in Access (or VB6 or Matlab or Excel).
Then IT has minor panic a contractor is given the job of trying to translate the "prototype" into "real" code and has a battle on their hands.
Often programming contractor doesn't have technical understanding of what model is doing, regardless of choice of language the code engineers write tends to look like Fortran (i.e it's essentially all math formulas), even comments probably don't help when they say stuff like "/* Ergun's formula to calc Delta P */" that doesn't mean a lot to someone without a chem eng background. I've seen contractors produce bugs by doing things like misreading a spec and adding a variable called Fe203 (i.e Fe "two hundred and three) instead of Fe2O3 (Fe "Two Oh three" - a chemical formula). You can't really blame contractor he doesn't know anything about chemistry - he was just hired to rewrite this monster in java based on a spec.
So I don't think its a simple as turning problem over to an experienced programmer and expecting success.
Re: Microsoft Access: The Database Software That Won't Die
#95This is the question I always wanted to ask, I almost wrote an Ask HN... Who use Microsoft Access in 2019?! An obvious case is creating a glorified/enhanced Excel for some specific office tasks, another case is that some applications use ".mdb" backend. But that's all? edit: What I'm interested in is cases of using Access for something other than a specific Excel-like office task - it seems Access is still used for s…
U.S. based brick and mortar casinos use a lot of older tech and at many of them, Access is still a vital component. One I contracted with recently had sort-of a data warehouse (a SQL Server db primarily consumed by Tableau reports) but the daily ETL process to move data from the CMS (casino management system) into the warehouse was 100% Access. Via macros, temporary tables and views, some individuals believe Access can be an effective ETL script writer. In reality it crashed regularly and when it did complete, best case scenario was it took 3-4 hours. A rewrite in Python reduced that to 12 minutes, with far fewer errors and additional computations along the way. Besides ETLs, Access is also popular in generating mail files -- a casino may send hundreds of thousands of physical mail pieces each month, the address and offer data is often passed to the printers via CSV which was generated by an Access macro. The industry has numerous well-paid people with "Database" in their job title, whose sole experience is with Access, and couldn't write a single line of SQL.
Re: Microsoft Access: The Database Software That Won't Die
#96I'm convinced that Access could replace 90% of the business/enterprise software being written today in 1/3 of the time. It's especially powerful if you use a connector to a real database and just use access for its forms and reporting capabilities
Re: Microsoft Access: The Database Software That Won't Die
#97This is the question I always wanted to ask, I almost wrote an Ask HN... Who use Microsoft Access in 2019?! An obvious case is creating a glorified/enhanced Excel for some specific office tasks, another case is that some applications use ".mdb" backend. But that's all? edit: What I'm interested in is cases of using Access for something other than a specific Excel-like office task - it seems Access is still used for s…
Why would anyone use Access in 2019 when they can use SQLite instead? Is it because Access has a graphical interface?
You can make a nice UI very fast. Forms, fields, buttons. It's nothing like SQLLite which is just an SQL engine.
This is like saying "why would anyone use dropbox when you can just run rsync on your Arch linux box."
Re: Microsoft Access: The Database Software That Won't Die
#98I will admit a love/hate for Access. Namely, from years of teaching Microsoft Office as Intro to Computing. Access was always the section that was hard to convince students they'd ever need and worse yet outright made the class logistically harder for Mac users. I will say, however, Access has SOME benefit to Information Systems education, especially in a general IS class. These students are marketing, accounting, et…
I wonder how many people became actual programmers due to Access. I feel like MS can't remove it just like you can't remove the second rung of a ladder.
Even if MS feels they can't remove it - the fact they haven't made any significant improvements to it (even those to keep it usable on modern computers) means it will die a slow death and leave people stranded - the same way they did with VB6.
For example, the SQL text editor in Access is so broken if you copy and paste tab characters they're displayed as zero-width and break text rendering (if you click+drag to create a text-selection the selection will cover the wrong text) and you usually get a syntax error if you make any changes to the query after pasting it (but if you don't modify it then it's fine). Never mind the lack of syntax-coloring or auto-completion. Microsoft says they are not planning on making any changes to the SQL text editor: https://access.uservoice.com/forums/319956-access-desktop-ap...
There's also a fun bug where the outermost LEFT OUTER JOIN in a query with 2 or more other joins will fail if the right-hand table has zero rows (but will work if the right-hand table has zero matching rows).
Re: Microsoft Access: The Database Software That Won't Die
#99Earlier quoted context omitted.
Why would anyone use Access in 2019 when they can use SQLite instead? Is it because Access has a graphical interface?
You can make a nice UI very fast. Forms, fields, buttons. It's nothing like SQLLite which is just an SQL engine. This is like saying "why would anyone use dropbox when you can just run rsync on your Arch linux box."
To me the main feature of both Access and SQLite has always been the fact they're single files. Very easy to manage.
Re: Microsoft Access: The Database Software That Won't Die
#100Earlier quoted context omitted.
I don't disagree, but isn't it a sign of much deeper issues if this "Shadow IT" land exists at your company in the first place? Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Are they under-staffed? Neck-deep in spaghetti code? Lacking business knowledge and the opportunity to acquire it? Bottle-necked by a lack of business analysts or testers? I he…
Re: Why is it that experienced programmers can't efficiently solve a problem that a business user can handle in Access? Because existing web UI standards suck rotting ass to hell and back. The standard was not meant for CRUD and still isn't even if you add gajillion layers of (buggy) JavaScript to emulate a real GUI. We! Need! A! Real! GUI! Standard!
Just master rails -g and you can be done in an afternoon.