Software

10 things I don't miss about Access

Database development is outgrowing Access -- and even some longtime Access developers aren't entirely sad about this trend.

Whether by Microsoft design or just the will of the database gods, Access development is waning. Most Access developers are now working with SQL Server or SQL Server Express with.NET-based and Web-based development tools. A few people are still gainfully employed as Access developers, but most of us no longer use Access for serious development work (much to our chagrin). Still, working with a big engine has its perks, and as much as I loved (still love) Access, there are a few things I don't miss.

1: Corruption

Even if you're an Access genius, corruption probably cramps your style occasionally. It just comes with the territory. Now, there are ways to avoid corruption, as discussed in 10 Ways To Prevent Access Database Corruption. The reality is that corruption costs you time and sometimes data. Recovering from corruption is never a fun way to spend a day.

2: The naysayers

When used correctly, Access is an efficient and dependable desktop database. For the last 15 years, it's been the bread and butter of many developers. Yet despite the popularity and capabilities of Access, some people ridicule Access and Access developers. I definitely don't miss hearing their trash-talk every time I recommend Access as a quick alternative to one of the big engines.

3: IT bans

Non-programmers build most Access databases, and the results are often inefficient and difficult to debug. As a result, some IT professionals refuse to support Access. I can't blame them for that. Unfortunately, IT often goes a step further and bans Access from the premises, which complicates things for end users. Waiting for IT to produce a non-critical database can take months. Often, the department just hires an independent contractor (how do you think I get most of my work?) instead.

4: Syntax error or access denied

Access is notorious for its ambiguous error messages. It's a frustrating inadequacy, even for those of us who love the "little database that could." The solution is intense error-handling, but not every project warrants that much development time, and sometimes you have to support a database you didn't develop. If you use Access, you have to deal with inadequate error messages.

5: Fixing someone else's bugs

Nobody misses this less than I do, but fixing someone else's bugs isn't exclusive to Access. Most of us don't enjoy fixing someone else's bugs in any application. It's difficult, it's time-consuming, and the person who wrote the bug is seldom (never) around to consult. It's just the nature of Access' end-user accessibility that makes bugs more prevalent and harder to troubleshoot.

6: Access haters

I'm always a bit surprised when a programmer spits out, "I hate Access!" Any explanation I might offer is suspect, I admit, but Access has a way of working its way into large-scale applications -- places where Access probably doesn't belong. After all, Access is an end-user product, not a development tool. It ruffles feathers more than a little. It's my best guess, but I'm still puzzled by it.

7: Missing references

Missing references cause common functions to stop working and the error messages are no help. You either know what's wrong, someone tells you, or your hair turns gray. It's an easy problem to solve and fortunately, it disappeared from later versions. Most of us are still supporting applications as far back as Access 9,7 though, so we still deal with it.

8: Broken promises

I wish I had a few bucks for every time I've received a call from the owner of an Access database that's not finished and the original developer is no longer available. Sometimes, the developer worked in house and moved on before completing the project. More often than not, the developer promised more than he or she could deliver and quietly disappeared. Trying to pick up where someone else left off is close to impossible. I seldom take on these projects and it's uncomfortable. You want to help these people, but you usually can't. They've already spent a lot of money and they have little to show for it. Trying to help just makes you a target.

9: Missing documentation

Because non-programmers build so many Access databases, there's usually little or no documentation. Seriously, most users wouldn't know what to document anyway because they use wizards to generate everything. That takes us to #10.

10: Wizard-generated code

Access wizards are ingenious; they're innovative and helpful tools. On the down side, they generate horribly inefficient code. Sometimes, wizard code can help you pinpoint an elusive object or property, but I don't actually use it. If I have to enhance wizard-generated code, I (usually) comment it out and start over. Supporting an application that's mostly wizard-generated code is tiresome.

About

Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.

89 comments
JJFitz
JJFitz

As an IT Director for a Biotech company, I think I can clarify as to why IT generally bans the use of (and occassionally hates) MS Access. It has been my experience that many "in-house" staff who build a database system are not trained dba's so they usually take a lot of shortcuts. They often fail to collect user needs. They often negelect to document how the database was built or how it is supposed to function. They often do not follow any standard naming conventions. They often release it before it is fully tested. They often keep IT out of the discussion until after something is released. They often do not justify why they chose to build a relational database when a simple flat file could have worked just as well. Some of the "Access solutions" I have seen would make Rube Goldberg jealous. :) That is why Access is not routinely installed on our company computers.

joanarbo
joanarbo

Many years before I was in charge of a project to build a new hospital. I asked one of the members of my team to ask IT for help to create and depurate a database with information we needed for population measuments. He came back and said to me, 'They promised to do something within a month from now'. I looked up to him and said, 'Please, see your watch and measure how much time I need'. Fourty five minutes after I had a reasonable instrument to get the results we wanted, in DBase! Then, I developed many applications in Access as head of Human Resources at an international bank. Without them, I would have never a full employee database, an employees' financial risk control mechanism, vacational monitoring, hiring and replacement follow-up, and so on; unless on paper of course. I left the organization four years ago, and the applications are still running, because our needs were - and are - at second place, after commercial, financial, operational and other urgent requests. In fact, they think our job can be fulfilled through writing on a notebook ... and good memorizing! So, we end-users will always need a good companion whatever the IT professionals think. Good article!

TheSwabbie
TheSwabbie

I started with Access 1.0 WAAY back in the mid 90's when Windows 95 was all the rage. My buddy and I got called into an Orthotics company who had an access DB (1.0 version). The Developer had also set up their Windows for Workgroups network so badly it was an abortion. We completely rebuilt their network (with a switch instead of hub) to a 100MPBS instead of a 10mbps with coax (rg58 & BNC connectors).. Lastly we tackled the huge database which even did their billing besides creating build orders for orthotics. We TRIED converting it to 2.0 with the conversion utility.. almost crashed everything. Nope.. the entire DB had to completely rebuilt MANUALLY (offsite) by us converting all the modules to the newer format. It took 6 months of work with BOTH of us after hours. In the end, we had a VERY happy customer.. I love access.. guess I'm just sentimental.

DonG43
DonG43

As I read the comments, I keep running into the term developer. While Access may not be appropriate for developers, it is difficult to name another GUI end user product which allows relationships to be set up. With the demise of dBase and Foxpro there is nothing an end user can use to go beyond Excel. And there is a lot of non-technical help for Access users. When I worked in IT, we always encouraged end users to consult with our people before developing an Access database so it would be "kind of" right. It got the user's problem solved quickly and it got a lot of these little "projects" off the IT schedule so our developers could work in mission critical issues.

Shadeburst
Shadeburst

The alternative in most companies where I've worked is Excel. They stretch Excel way past its design limits to produce things like Bills of Materials, with lots and lots of manual input (and resulting errors) because the average user can't even write a VLOOKUP() function. At my last client, a firm of consulting (insulting?) engineers, I tried to teach the otherwise computer-savvy execs to use Access. Total mental block. Next time I looked they were back to using Excel.

wrmosca
wrmosca

I'm an Access MVP. Have been for 5 years. And I've been developing Access applications for more than 12 yrs. I'm one of its champions, but I have to agree with just about everything you wrote, Susan, and I've given up on using touchy Access tables. My apps are all front ends to SQL Server databases. My # one pain is picking up where some moron left off and trying convince the client that the best thing to do is start from scratch. . But don't go trashing Access for the lack of documentation. I've supported million-dollar software where the lack of documentation is blood-curdling. It ain't the tool; it's the carpenter. And as to IT hating Access...when I was hired I was told the IT department did not support Access and my duties would change once I completed the project I was hied for. Guess what! Once they saw what Access developers could really do I got more work than I could handle. 7 years later, I'm still developing custom applications along with the "other duties".

beck.joycem
beck.joycem

I've had a great deal of "fun" in the past trying to disentangle other people's badly made Excel or Word work, but I don't hold Excel or Word to blame! I think that those who draw attention to the way Access turned out to be more powerful than maybe MS expected, and in particular that it's ease of rapid development enticed people into using it for 'big' applications have probably hit the problem on the head. I am guilty, and I'll bet I'm not alone, of creating an Access app for what was meant to be a short term problem, then adding and modifying it over several years until it was a mess. My priority was doing my job, oddly enough, which was reconciling three stock systems - the Access app was a tool that I, and only I, used to do parts of it .I didn't blame anyone else for its sorry state, I didn't expect anyone else to support it. Now I have a couple of little Access apps which supplement QuickBooks - again, nobody's business but mine. I think people are blaming the tool for the results, like blaming the saw for a badly made table.

ssharkins
ssharkins

The built-in documenting tool is great for documenting relationships and properties, etc., but I don't think all that is particularly necessary. Developers need to document their design and strategy -- why they chose a particular route, why they chose an unusual route when something else is more obvious -- at least, at first glance. Those are the things developers need to document.

jamescox
jamescox

Guilty as charged on 9. Missing Documentation Having spent a LOT of time in Excel before getting drafted into supporting Access db's others had created, I came with a bias for doing everything in VBA. I can (and do) document my VBA code in Acces db's, but the multiplicity of ways of doing things in Access (Access macro vs VBA 'macro', 'named' query vs typing a query string into a recordsource / rowsoure field vs generating that query string on the fly with VBA, etc, etc) makes it hard to create more global documentation. There may be commercial tools that could help, but getting approval for them ("We don't support no stinkin' Access.") isn't easy. So.... Does anyone have any good quiding principles for documentation? (Keeping in mind "here's how to develop in Access so that documentation is easy" comments may be helpful for new work but won't be so useful in trying to understand / document / maintain / extend an Access db I may have inherited...)

nmeyer67
nmeyer67

Really, To have made up 10 points like you have, you must not be actually using Access anymore. #1 hasn't been a problem since Access 2003. #2, 3 and 6 are just the author disliking bigots. I dislike them too--but they aren't three separate points. While the new Office 2010 help is almost useless, the Access 2003 VBA help was very good, and what you couldn't find, you could Google. Access has a VERY robust community surrounding it. VBA in general does. What you can't figure out for yourself, you can very likely get someone to give you a hand with at sites like Experts Exchange and Utter Access. The Access Web is another outstanding site, as are Allen Browne's site and, though he no longer maintains it, Stephen Lebans. Try getting that level of help on something like SharePoint. Fuggetaboutit! The author admits that point #7 is rarely a problem anymore. So that leaves #5, 8, 9 and 10 #10 is a self-inflicted wound. If you don't like wizard-code, don't use wizards. If someone else's wizard-code annoys you--well that's #5--and I will certainly agree that maintain SOMEONE ELSE'S code is a bugger. Especially if they are amateurs...but what does that have to do with Access specifically? Maintaining amateur ANYTHING is a bugger. VBA, javascript, HTML, ASP, you name it. No Fun! And #8 and 9 are really the same thing, too. It's no fun to clean up a mess. Alright, so we are left with an article that says the author doesn't miss the fact that Access attracts the ire of bigots and can be used by amateurs. True enough. Next time, Susan, try and post something a little more substantial about how the bigots could be de-fanged and the amateurs, reined in, guided and taught best practices.

Kent Lion
Kent Lion

These are Microsoft problems. There has never been a time when errors generated by Microsoft applications were not essentially useless.

Peleg
Peleg

because it really doesn't very well address the technical capabilities of Access. Perceptions of those unfamiliar with the product, office politics, and failed attempts by non-programmers aren't the basis for valid complaints. Corruption is one perhaps valid problem, but as soon as you just slap a real client-server backend onto Access (make your own choice: Oracle, SQL Server in any of its flavors, or my favorite, MySQL), all of the corruption problems go away. It is remarkable to me how backend-agnostic Access is as long as you've got an ODBC driver for it. If you simply have the right approach, and make proper use of the rich set of events, you can (at least I can) create really industrial-strength and battle-hardened applications. Access can be a thought of as an end-user tool, and it does pretty well at it, but if you are a capable programmer, VBA gives you just about everything you need to create the application that you want. And if you can't do it in VBA, write yourself a function in a DLL and call that function -- but I've never had to do that. I have a procedure that reformats and corrects addresses to conform to the USPS standards. Integral to the procedure is a hash table. It uses Scripting.Dictionary. Advanced features are there, you just have to find them. How many people use Regular Expressions in Access? I do all the time. RegEx's are very handy to validate user input. Perhaps the problem is not that Access can't do it, it's just that the programmer can't do it? As for error handling, I have for years (I've been doing Access for about 15 years) inserted into every procedure default error handling using a procedure that I wrote along with a simple macro to call it. When my apps die unexectedly, at least they do it with some grace and provide at least some sensible information about what went wrong so I can go back in and fix the problem. Most of the time, knowing text of the error message and where it occured are all I need to know what I missed. It has been my experience that whenever I hear someone throw bricks at Access, they really don't have any real knowledge or experience with the product. As IT people, especially the people who maintain the networks for a living, are NOT programmers, their technical opinions about a software product doesn't count for much. I don't offer my opinion on which is a better router because I know I don't know anything about them. I'd like to hear the same humility from networking folks and admins. But this is what I have to put up with as an Access programmer. Access really is the Rodney Dangerfield of software.

msimms
msimms

I see very little work being done in IT departments today to truly support the end-user. Instead, IT has created a huge set of rules and policies for every to follow. Also most of their time is spent justifying their existence (and large salaries !). Lately, one of the rules is : "No Access Development". It's true: I live in a large Metro area and there are rarely more than 1 or 2 new requests for contractors for Access every month. On top of that, support from Microsoft has been waning at best. In fact, I don't think they have a product manager any longer. Access 2010 has introduced some great new features and alas a ton of nasty new bugs that are still not fixed as of Office 2010-SP1.

ssharkins
ssharkins

My first experience with Access was 2.0 -- was totally amazing back then and there was no VBE! ;)

Tony Hopkinson
Tony Hopkinson

when my job title was Junior IT support assistant. Don't mean squat. If you are writing any thing from a query, to macros to a full on application with it you are developing. Whether access is suitable in this case depends on the development not the developer. Anyone who's decent in acess, could reasonably easily become proficient in .net and a DBMS and vice versa, if that was where their interest lied. It might not , but they opened up access to find out how frequently they ran out of stock of purple lipstick, not how to optimise a database and application to store stocking data...

Tony Hopkinson
Tony Hopkinson

to do word processing. He was chuffed with the result. Sort of like a dancing bear isn't it. Okay It's not Valentino, but what do expect from a bear. Anybody remember Lotus Approach. Runs off screaming...

ssharkins
ssharkins

That's a nice ending -- I think lots of Access developers would love such a happy ending. I love Access and when I said these are things I don't miss about Access, I meant that in an inclusive way -- all facets, the environment, the process... I wasn't just picking on Access faults, but rather, saying, "these are things I don't have to deal with too much when using SQL Server -- lack of documentation is one of those issues. It's the nature of the beast -- Access is not part of the conventional IT plan, so end users don't document what they've done, many developers don't even bother. Yes, it's a developer's problem, but it's been my experience that it's a bigger problem with Access. Just my experience though. Thanks for sharing your story -- we need to hear more like this one!

Tony Hopkinson
Tony Hopkinson

Did loads of good stuff with it, and learnt a lot, right tool for the job is all it is. Access's bad rep mainly comes from picking it even though it's the wrong tool, (or later turns out to be, and refusing to admit it). That isn't specific to acecss either. We've had more than a few threads on here about being brave enough to pull the plug on a bad project. Most agree it's a good idea for other people's projects they think have gone bad... :(

Tony Hopkinson
Tony Hopkinson

Code rot and technical debt just is. It's a fact of life, All the real problems come from pretending it isn't, like buying the next big thing. You know the one that makes you bettre in bed, reverses baldness and makes politicians honest... Rule one, by the time you write the perfect software you need 'now', you won't need it anymore....

ssharkins
ssharkins

I think the underlying problem is just education and training. Why do managers expect folks to just know how to use these tools correctly? All kinds of trades have apprenticeships, interns, etc. But, I guess we're just born knowing how to create spreadsheets, documents, and databases. :) And if you confess that you don't know how to use the product, you're told to learn, read some tutorials, watch some MS training videos. Well, I guess it's a start at least.

Tony Hopkinson
Tony Hopkinson

If you don't start with it, you definitely won't finish with it. Hiding to nothing this one, not specific to access either. Best advice is to try and standardise, always used named queries, come up with a naming standard. If theres a auto start macro call it auto. Have a standard layout. Chhose something that suits most of the time, document exceptions Documentation, won't get done, it will get out of date, it will be written with a bucket full of assumptions, and you will never get on top of it. Do stuff to cope with that, it is what it is.

msimms
msimms

What exactly makes this help so bad ? Why wouldn't it just be the same help as 2003/2007 plus the new features ? Are you indicating they removed some items ?

msimms
msimms

What specifically is the problem with this 2010 release ? You are aware that older AC2003 apps were all kind of "fugly". AC2007 brought on some major functionality and improved astetics that quite frankly I can no longer do without. I actually quit one dev contract when their IT department (HERE WE GO AGAIN) would not allow me to use AC2007....I was FORCED to use AC2003.

ssharkins
ssharkins

I do agree that the new Help feature is useless. To clarify, I didn't say I used wizards, I was talking about supporting someone else's wizard-generated app.

Tony Hopkinson
Tony Hopkinson

but I wouldn't describe her as ignorant. Rein in the "amateurs"? Whats one of Access's biggest selling points?

Tony Hopkinson
Tony Hopkinson

On Error Resume Next Followed by Blue Screen of Death. :(

seanferd
seanferd

But I didn't see that strawman you are using for a premise pass through the article.

ssharkins
ssharkins

As stated, it's just commentary -- the things I really don't miss at all. I'm not misleading anybody about anything. I love Access -- I'm certainly not throwing bricks! I'm one of Access' few champions. You're not real familiar with my work, are you? ;)

Tony Hopkinson
Tony Hopkinson

Using a full DBMS backend solves a lot of problems. Do you know how rare people like you and Susan are in Mainstream Access environments. Regular Expressions?, these people haven't come across Like. I had one twit spend two days arguing with me that his system was client server because his MDB was on another machine! Your suggestion that Macros and VBA are suitable vehicle if you know what you are doing needs to carry a health warning. I can't imagine trying to control the sort of projects I work on with access as the tool of choice. No typing, scoping, contracts, exceptions, no thanks...

Charles Bundy
Charles Bundy

Rules or laws. I could see a tightly stretched IT dept. saying "we won't support yer Access database." From your text it sounds like Access is available on the desktop. Short of not installing it how would they prevent development? BTW if they are working their arse off maintaining the infrastructure you won't see them "doing a lot." That is a good thing :).

Tony Hopkinson
Tony Hopkinson

So why are they allowed to do that then? I mean if they are failing that badly, the people in charge would sort them out wouldn't they? Next time someone in the business comes out with this bollocks, ask them why they are allowed to..... Or keep your gob shut and save your career from being derailed through inflicting reality on conforting management perceptions. It was 'im... In fact It was IT.... Sheesh.

beck.joycem
beck.joycem

Remember it? I know of a business still relying on it for a mission-critical app!

jdowski
jdowski

"Access is not part of the conventional IT plan....". Isn't this the crux of the problem right here ? I still say IT & the businesses should be partnering more on Access projects. If IT were involved in the beginning, apps would be more likely to be better documented and developed and ready to move to larger (fully IT supported) platforms should the need arise. The current enviroment leave both the Business & IT frustrated.

ssharkins
ssharkins

I worked with Paradox just a bit years ago -- I admit... I had trouble getting my head around it. I know many who absolutely loved it though. I get lots of inquiries from people wanting me to "fix" an Access database or wanting me to finish one. For me to take on a project like that would require baskets full of money. It is difficult to follow someone else's trail in an Access database -- Okay, it's always difficult, but Access is worse because there are so many directions one can go with almost every task and if the existing solution doesn't take the path you think it's most efficient/best/whatever... it's just... I don't feel challenged, I feel overwhelmed by the process. Of course that's the very reason so many people love it too -- paradox. :)

ssharkins
ssharkins

People have strong opinions sometimes. As for selling points -- well, I would say its end-user accessibility and it's rapid development.

ssharkins
ssharkins

No intentional strawman scenario, so I'm not sure what you mean.

jdowski
jdowski

You don't think much of Access. However, for many of us not in IT it is the only tool we have. Perhaps if IT departments were more accommodating with their time & resources folks on the business side would be more willing to engage them. However, it's been mentioned several times in both the article & comments here that it can be very difficult to get a IT project approved, funded, and then completed in a timeframe that works for the business. In fact at times IT seems to act like they are the business. They are a support function to the business.

ssharkins
ssharkins

Tony, are you really suggesting that an end-user challenge the status quo? That could be bad -- I wouldn't recommend it, but then, you might call me chicken, but yeah, I admit that. I would only challenge, if I were ready to leave my job anyway.

msimms
msimms

Actually IT departments are getting away with it. I've been to meetings that nearly ended up in fist fights. Too much politics, too much contention for IT to be effective today. So to make themselves look good, they disable end-users from doing some of their work. Slick, eh ?

ssharkins
ssharkins

I sometimes find it easier to write the SQL and of course, there are times when you have no choice. But I find the GUI intuitive and helpful. I think most end users need that GUI. And, I often start in the SQL window when writing code because those error messages are so much better than VBA's (which are mostly, atrocious).

Tony Hopkinson
Tony Hopkinson

Access always feels pretty constrained to me. Might be more down to self teaching. One of the reasons I don't like access, is I find it very difficult t relate the Gui to what I want to achieve. I'd rather write raw sql, following Tony's tried and tested decription of a database. Other's aren't going to get my naming conventions, and perhaps not my general approach. Doesn't make it more or less professional, or mean taking on a half done sql server / C# project is inherrently easier or harder than an Access one. It's just familiarity.

Tony Hopkinson
Tony Hopkinson

Would access have taken off without the gui table designers, and QBE? Like any good thing, a little bit of effort and you can make it a bad one...

jdowski
jdowski

Hi Sean, if you're referring to my comments regarding IT supporting Access, what I mean is that if folks are having issues and they go to IT, they should be able to schedule time with an IT Access Dev and go over the application and what might be done to improve performance. I did not mean that the Dept would go to IT with, "We wrote a crummpy app, it's up to you to make it work....". My idea is that IT would not "own" any of these apps but just offer different level of technical advice & support, up to & including migrating off of Access to another platform is that is what makes sense. :)

ssharkins
ssharkins

They're all different, with different priorities and rules. Many companies have a total ban on Access -- end users can't use it period, with or without IT support. An awful lot of companies don't have a support/help desk position.

AnsuGisalas
AnsuGisalas

It's a managerial matter whether or not you get tasks that require a tool like Access. It's a managerial matter to select the brand of tool. It's a managerial matter to allot resources for training and user-support (as opposed to software support, which is something else entirely). So go talk to your boss, and don't let him push the monkey over on IT's shoulder.

ssharkins
ssharkins

I think giving end users tools is useless unless you provide training or provide someone in-house who can help guide and answer questions. I wouldn't make an end-users app someone else's responsibility -- but rather a help desk of sorts perhaps - someone to actually help and support -- not fix.

Tony Hopkinson
Tony Hopkinson

So I gew a brain, installed it in my managers head, started suppoorting their efforts while there was time to direct them.... It's not hard and it uses a lot less resources than getting dumped on.

seanferd
seanferd

And I don't see why an IT department in an enterprise should be "supporting" (read: doing it for you) any Office app. Either you know how to use Word, or Excel, or Access to do what you want or need, or you don't and you learn how. I didn't throw Powerpoint in there because everyone and their mother knows how to abuse Powerpoint. They are desktop apps. Call the help desk if they do training for desktop apps. If you don't understand the applications that you want to use, study up. The knowledge will make you more valuable, all other things being equal. Figuring out what you did wrong with your Access DB project isn't doing anything to increase the value of most IT people for the company or for themselves. But if you have just a plain old crappy IT department, just say so. But support for Access is the least of your worries in that case.

ssharkins
ssharkins

I wouldn't encumber IT with supporting apps they haven't designed/developed. What I would like to see is a more lenient policy toward letting end users use it. But no, I know Access too well -- you don't want the responsibility of supporting someone else's work -- might as well put a bulls eye on your back.

Tony Hopkinson
Tony Hopkinson

The business does..... So given that tiny flaw in your logic, perhaps you'd care to expain what we get your highness? And as stated earlier I'm not against Access. I'm against being lumbered with accountability for something I had no part in designing, didn't know was coming, designed by people I have no control over, for a purpose I know nothing of, to standards I had no part in making, with a tool I don't use. Now if that position doesn't make sense to you, I can tell you exactly why you are having so many problems with your IT people. Stop being part of the problem, try being part of the solution. If I was in your IT department, you'd be beavering away with access, and I'd know the basics of what you were doing and I would be helping you help me and I would be helping me help you. I'll bet you have some allies in your It department`, well before you opened your gob. Doesn't matter how brave a rear guard action against supporting access we fight, we always lose some and Murphy's law usually means it's the one where YOU'VE moved on to better things, and no furker else has a clue where to start, and well it's IT isn't it so we must know all about it. I aren't new at this stuff you know...

Tony Hopkinson
Tony Hopkinson

Can't challenge management, yeah okay. A department's priorities, don't be silly.

msimms
msimms

is that many employees CANNOT CHALLENGE the IT department without some backlash and/or job dismissal. Look....technology is critical at some companies....and that makes IT almost "sacrosanct" to the point where their decisions are never scrutinized.

Tony Hopkinson
Tony Hopkinson

that it's not career enhancing, for those who have management in mind. LMAO :D

Tony Hopkinson
Tony Hopkinson

years on shifts doing basic clerical and data entry. I've always been a big believer that you get the big things like profitability right, if you get the small things right, like the columns the right way round on a data entry form. If making the iob easier, efficient and less error prone isn't imporant, then the task isn't, you isn't, so sod it, right? Why should you be invested in it, proud of, feel like you are contributing, when some arse won't take a few minute to fix something as basic as the columns are the wrong way round on a form? That isn't an IT decision it's a business one.

ssharkins
ssharkins

End users have work to do too... ;)

Tony Hopkinson
Tony Hopkinson

So do you apparently, in that you think the end user is the business. You both need to lay off the corporate cool-aid for a bit, before the damage becomes permanent. IT is there to serve the business, and your case included, the business must think it is being served. You described those business people as idiots. Those are the people in charge. it's their responsibility not to be stupid, or at last not to make a habit of it. According to you all these failures are the first step of the evil genius IT boss' plan to rule the known universe! Or maybe just maybe. Some one figured he could get promoted by showing a drastic reduction in this years costs, because next year well anything could happen, and the next contatestant in the game of corporate musical chairs can get tea and medals for turning the entire situation around. Don't listen to what they say, look at what they do, and follow the money.

wdvs88
wdvs88

IT is supposed to exist to service the business, but in the companies I worked for the executives had little clue about the systems so the IT people were not questioned very much. I work for a company now where the IT manager actually convinced the managers that ":IT only does hardware, they don't do software", AND THE IDIOTS BELIEVED IT! I pushed for awhile and gave up, until they bought some Intelligent Business software, which have us access to the ERP server database. They didn't even realize this also gave me access to it through ACCESS. After I developed a few databases that gave them reports they couldn't get out fo the ERP system, the managers realized the importance of me having ACCESS and let me have all the access I could handle. There is really no chance of corrupting the main system since I am only doing read-only links to the tables. Now maybe you're one of the IT guys who really helps out the little users (Materials Dept.) and doesn't totally ignore them to only help out the Accounting or the Sales departments, but a lot of your brethren do ignore anyone who isn't part of the aforementioned departments, or are not responsible for their budgets. Maybe we need a survey to find out what percentage of users are being hampered by mistrustful IT departments. If you embrace your super-users as a resource, you'll find your workload decrease and you can make the budgetary guys (Excecutives and Accounting) happy.

Editor's Picks