December 13, 2010 at 10:08 pm
Comments posted to this topic are about the item The Low End
December 13, 2010 at 11:36 pm
I'll agree with this. In our neck of the woods, particularly, Access seems to take the most heat. That's primarily because it's used and abused compared to what it's supposed to do, but it is a relatively robust piece of software for the $200/seat extra cost from Microsoft Office.
Your average mom and pop shop using an inventory system doesn't need Oracle or SQL Server in the backend... they need a single pc, maybe two, with Access installed and a decent backup system. We've all seen the horror stories when there's 100 people on an Access DB, but it's perfectly fine for 4-5 concurrent editors that are keeping their data to reasonable volumes.
Then there's prototyping. It's hard to find an easier to use front end that you can quickly prototype out some reports and front end forms, or to simply create a fast interface, to a SQL back end. Occassionally a prototype is really all you need if you're generating a troubleticket system or whatnot. Deploy the front end out and leave the SQL server doing the heavy lifting. You just saved yourself a headache and a half trying to do a full intranet project.
There's a time and place for software like this. Small shops or IT only fast interfaces are the first two that come to mind. There's power in a dollar saved.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
December 14, 2010 at 1:23 am
I don't actually have a problem with using VB to create applications--VB.NET removed the most annoyingly retarded elements of VB6 and is a much more robust development environment. The issue is with poor development practices, not the languages or programs used for development; yes, VB and Access lower the entry bar and make it easier for non-developers to create stuff, but I think the main issue is one of training, not one of the development environment.
December 14, 2010 at 1:48 am
Access is a superb piece of software. The ability to quickly create a UI linked to SQL tables has been invaluable in my current job. It's been used to create a Change Control system and a Project Tracking system. The DBs are in SQL Server and as such are robust and backed up regularly.
The systems are used by a department of approximately 30 people and we never have multi-user problems because each person has a copy of the Access mdb pushed to their PC. We've even devised a system whereby when we update the UI it is auto-pushed to the user the next time they access it.
Where we do run into problems is if people have MS Office other than 2003 installed, as differing versions of Access don't always play well together. As a rule we only support 2003 - the most popular install by far - and it's a wider IT problem as to when 2010 is rolled out.
I've had to defend Access many times, and whilst as a DB it can't stack up to the power of SQL, I've often said to people "You build a UI in SQL and I'll build one in Access, and whilst I'm waiting for you to finish I'll be over here having a nap!"
In other words, it's a great tool for the right job.
December 14, 2010 at 1:56 am
I've always considered Acces and VB, macros and so forth as very good tools for prototyping.. getting something that both looks and works the way the customer wants very quickly.
I started as a developer and only in the last 3 years been exclusively involved as a DBA. My very first programming job was writing 68000 assembler code, and being able to get both an interface UI and functionality working so quickly is a huge improvement.
Of course, if you've ever looked at programming on a modern Mac, you'll know how far behind tools like Access and .NET really are.
The problems come when customers see the prototype and don't appreciate that this is not the final product, or how much more robust the final product could be.
DBA (Dogsbody with Bad Attitude)
December 14, 2010 at 2:05 am
I find that the low end software should only be used as a precursor to development to enable the development team to collect and collate the data and the users have the ability to understand what they ask for and the effects of their request on the requirements.
The development team will have some real life data to test their development with.
December 14, 2010 at 3:38 am
The "trouble" with Access being so easy to use, is that the skills aren't just limited to IT staff.
I'm sure I'm not the only person to be caught out be the following scenario:
A switched-on user in Department X creates a quick application in Access to help with their job. It proves useful, so he gives access to it to others in his department.
At some point, the main user leaves and then the system invariably goes wrong - IT then get a call and are asked to fix the system that the department can't live without, and yet IT know nothing about.
A busy day of backwards engineering ensued!
Tim
December 14, 2010 at 5:58 am
There's nothing wrong with a tool perse, but it depends on the skill and knowledge of the person wielding it. Just because you have a hammer doesn't mean you know how to build a house.
Or, more than once in my career, build a 4 story office complex. Only to come to IT when they realize they're in over there heads to "rescue" and complete a project that, given the requirements, SHOULD be scrapped and started from scratch.
December 14, 2010 at 6:02 am
I must say, I kind of resent the moniker "low end products"! Younger techies do not realize the huge impact of systems like Foxpro/Visual Foxpro, Clipper, dBase and the other Xbase products. For some 20 or so years these systems were "the" systems at some of the biggest companies I have worked for, including IBM, Marriott and Chase!
If like me, you came up in this age, Access and VB were in fact jokes. Overly complicated and not tailored to good development, nevermind poorly supported - it was the Xbase products that shined. And let me correct you at once - these DID NOT result in "buggy" code! Witness that Merrill-Lynch ran Clipper apps for over 30 years! IBM depended on FoxPro for some 20 years! The immediate assumption that we needed someone to police us to write good code is a bit insulting.
Let me also point out that RAD (Rapid Application Development) - a buzz word and tactic back in those days - existed because of these small scale systems. Try to do an entire complex application in .NET these days! In FoxPro we built an entire Facilities Management system in 42 days!!! NOT buggy! Try to do that in .NET and I wish you good luck.
As well, where you are painting this age as a bunch of hacks spewing out buggy code - I beg to differ! This was a time when creativity and good code was produced quickly, providing apps for small and medium business in a cost-efficient manner! Go out now and try to buy say, a CRM system for small business. You will spend probably 100 times what would have been spent in those days and what do you get? A overblown beast, badly supported, poorly documented, and buggy application. Want support? You'll be paying for their mistakes. This DID NOT happen in those earlier days.
In 1984 Steve Jobs ran a commercial showing all computer users marching in lock step, each doing the exact same thing - then a woman comes through and throws a sledge hammer at the huge screen where some dictator shouts his orders. Know the commercial? Its on YouTube. Take a look at the freedom to be creative Jobs was advertising.
...now look where we are today. All marching in lock step as though there is only ONE path to creativity. Baloney!!!
When you speak of this age gone by, don't trash it. What you have today is there because of those of us who used these amazing systems to make good money, and produce excellent code. Oh, and by the way, some of that code is still out there running just fine. At IBM... At Marriott... and plenty of other very large AND small AND medium companies...
Now think about that and then show me how the heck any small or medium business can afford systems like SAP, MS CRM, or the other overblown, overpriced, buggy behemoths that take years (now) to develop.
December 14, 2010 at 6:02 am
A switched-on user in Department X creates a quick application in Access to help with their job. It proves useful, so he gives access to it to others in his department.
At some point, the main user leaves and then the system invariably goes wrong - IT then get a call and are asked to fix the system that the department can't live without, and yet IT know nothing about.
And that's exactly why we are not allowed to support access databases, other than to convert them to SQL Server with a web front end (VB.Net) all hosted on IT dept managed servers and properly backed up.
Access is fine for domestic use and prototyping but has to be strictly controlled for business applications, otherwise important and often personal data gets stored on local pcs with no backups and no relation to central systems. I've seen it go as far as users swearing they've updated the central system when in fact they've updated someone's local access db thinking it was THE system and the business was losing money as a result.
December 14, 2010 at 6:28 am
tim.short (12/14/2010)
At some point, the main user leaves and then the system invariably goes wrong - IT then get a call and are asked to fix the system that the department can't live without, and yet IT know nothing about.A busy day of backwards engineering ensued!
Tim
And this also describes what I encountered in several companies over the past 30+ years when "main user" and or "IT guy" left. In their day these systems were developed by "professionals."
In short, it's not the tool, it's how you use.
For speed of development I haven't found anything faster than Access for creating custom queries and reports against SQL server databases than I can quickly turn over to users to run.
Because it passes what appear to be optimized queries to the server, they also execute extremely fast when the job stream is written correctly.
Our IT department prefers IEV which I have found takes 5-10 times longer to develop in and 2-3 orders of magnitude longer to execute. They have the luxury of development time and don't care how long it takes to execute when the user runs it. I do.
In fairness, I will say I am doing significantly more work in TSQL than I did even 6 months ago. If I dared turn users loose with SQL Server Express, I'ld probably create all the end user stuff in it. I can't, so it looks like Access it is...
December 14, 2010 at 7:16 am
The benefit to these tools, especially Access, that I think a lot of developers don't get is that it creates work for programmers. To clarify, back in the day when I did consulting I got tons of projects where people (usually a paralegal or someone's teenage cousin) built a simple app in Access for a small need. Once they had an app, they realized how much information systems could make them more efficient and began to depend heavily on them and bolt on components to add functionality.
Of course, these systems were generally poorly architected, and eventually required calling in an expert to figure out why they were running so slowly, crashing, or just to add features that their "local expert" didn't know how to implement. Voila, a consulting contract!
I know what you are thinking. It would have been much better for them to have built it right from the start. However, a lot of these companies would never have considered automating it if they had to look at a quote for programming services early on. After all it's just a "small project that will probably only get used by a couple of people." They have to see the benefit, and how small systems inevitably turn into large mission critical systems before they understand the value and are willing to assign some budget to the effort.
December 14, 2010 at 7:16 am
As always: pick the right tool for the job.
If it truly is prototyping or small non-mission critical systems, knock yourself out.
My issue starts when the system is known to be critical to the business, yet the development is done with tools like Access, because its easy and the dev can bang it out, by themselves, in days/weeks instead of weeks/months. A steaming pile is delivered to the business units, then I look like the bad guy when I am asked for help.....because my answer is usually to create a proper relational database in SQL Server and to re-write the application. Basically - press the reset button.
I've been going through this cycle long enough to wish Access did not exist.
December 14, 2010 at 7:23 am
Access, VB and the other tools mentioned are useful for people to work out concepts prior to paying for having it coded in a higher level language. Also, in larger businesses where there can be barriers to getting approval of programming requests, Access, VB and such provide a means to automate tasks that may not be seen as worth IT's time and resources, but can provide a quick and flexible means of automating tasks and processes. The problem is that these quick and flexible apps grow over time and become major systems that are completely off the radar.
December 14, 2010 at 7:29 am
I'm reading all these comments about how Access and VB and .NET are horrid compared to the competition. Sure, there are a few "it's not the tool..." comments but for the most part I see disdain.
In the database world, I cut my teeth on Dbase II, went to Foxpro and used it to successfully create a dental office automation system back in the IBM PC/AT days, so I know and have a soft spot for the dbase era. Before that any programs I wrote didn't have database components, so you had to roll your own. *That* was a lot of fun--not. 🙂
However, I opted for Access back in the 1.0 days and never looked back. I've used Access (up to 2003 version) to fully automate a business over the last 10 years for a company of about 200 employees over 10 offices across the midwest. I have about 20 concurrent users and about a gigabyte of data (keeping 2 years online) and Access still works fine. Note I'm the *only* IT person the company has!
We're in the process of upgrading to SQL Server / VB.Net because we're *finally* starting to hit the wall, but having developed our Topaz program over that decade I'll tell you Access simply *stomps* on SQL Server for ease of development/speed--even considering all the robustness requirements for mission critical software.
*Used correctly* Access is a formidable development environment for SMB's. True, it doesn't scale all that well, 25 concurrent users is about the limit, but within that limit there's nothing that can touch it. While SQL Server can scale to thousands of users the experience you can deliver to the end user isn't any better--and the development effort is far greater.
Of course, I'm speaking as a professional developer. There's a world of difference between an application I would develop in Access and one developed by end users/power users. I've seen the horror when Excel users try to develop applications in Access. I can tell you stories that would make you weep.
But it truly isn't the tool, it's the developer.
Notice I haven't talked about Mac, because I don't develop Mac software. I don't talk about Oracle (shudder) because I want to put that painful time behind me. Powerbuilder and its frameworks (and the frameworks based on the frameworks), well, let's just not go there...
My point being, the only tools you should really trash are the ones you use every day. You know their strengths and their weaknesses, you know their paradigm. I would no more talk about Mac development than I would mainframe development.
It's not surprising a SQL Server user would sneer at Access when they've never really mastered it. Likewise a non-OOP developer would sneer at .Net, or .Net at Java.
The best critics of a system are the masters of that system, not someone who's never used it. Keep that in mind, ok? 🙂
Viewing 15 posts - 1 through 15 (of 34 total)
You must be logged in to reply to this topic. Login to reply