I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
+1
A:
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
CodeSlave
2010-09-02 14:37:21
Ahh, but those disadvantages you state are actually good things. One being that they didn't use Excel. The fact that these databases have grown and have become critical also means that the IT department should be reviewing these and getting them cleaned up. By a pro.
Tony Toews
2010-09-02 17:08:40
I have never found that one of these apps is so bad that it needs to be chucked and started over (and much of my work consists of taking over such apps and bringing them in line with new needs/requirements). And, frankly, it's the apps developed by self-styped "professional Access developers" that are often the worst! The ones created by the receptionist or the summer intern are almost always point-and-click operations with a bunch of macros and a sprinkling of wizard-generated code. These often have denormalized schemas, but the apps are trivial.
David-W-Fenton
2010-09-02 18:42:15
...as opposed to the ones created by the "pros" where things are often an order of magnitude more complicated than necessary. On the other hand, they often have better schemas, but that's completely offset by how much time it takes to untangle the mess.
David-W-Fenton
2010-09-02 18:43:09
@Tony, I would assert that the users figure out they are in trouble much sooner with Excel when they see pages and pages of data. Anything to drive them to IT sooner.
CodeSlave
2010-09-02 20:05:39
@David, If you've never found one, boy do I have one for you to see. It was created by someone with a PhD, not in an IT related discipline. The worst part is, I can tell they thought about it when they built it. But it's buggy, full of magic numbers, full of global vars, the program flow and UI changes diverges from any known standard, labels acting as buttons, buttons acting as labels, and it re-writes its self on the fly. The math has been done, it would cost more to make it good than to rewrite or buy new. So it will persist, warts and all until a replacement can be fit into the budget.
CodeSlave
2010-09-02 20:32:15
I was brought in a few years ago to start a project from scrath that had been attempted in Access by a Ph.D. in CS from MIT. So, yes, I've seen crap, and it was worse than what the naive computer user (the legendary receptionist) would have created. There was nothing to salvage from it and we started from scratch. The project eventually failed because the boss was completely bonkers, but they did end up with an app that worked (it was just never completed as planned).
David-W-Fenton
2010-09-03 15:36:59
+2
A:
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
Kevin Ross
2010-09-02 14:41:30
The situation with Access is similar to the one with HTML. The HTML you find out there in the wild is mostly horrid and awful -- it won't validate, and it's just "tag soup". But it's easy and people are able to make it work and the browsers are very forgiving, so the result is that useful things can get done with bad HTML. Access is very similar -- the fact that so many people can create piles of crap with it is a FEATURE not a BUG at all.
David-W-Fenton
2010-09-02 18:39:17
A:
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
Jeff O
2010-09-02 14:54:26
+3
A:
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
David-W-Fenton
2010-09-02 18:52:14