Take the 2-minute tour ×

MS Access gets pooped on a lot because A) many newbies use it B) people use it as a database backend which is not a good idea.

I'd like to see some reasonable discussion on why you might choose VB.Net over MS Access or vice versa for programming a Database GUI (forms and reports) to be used with MS SQL Server.

share|improve this question

closed as not constructive by gnat, ChrisF Sep 14 '12 at 14:29


VB.Net vs MS Access cannot possibly be a serious discussion. –  Job Feb 14 '11 at 23:27
@Job if he said C# vs MS Access, I might have believed him. –  George Stocker Feb 14 '11 at 23:40
While you might be able to use MS Access as a SqlServer front-end (I've never seen it before), I can't imagine why you'd want to. –  Michael Todd Feb 14 '11 at 23:44
@Job @George OK guys, I plead ignorance. I've read about the differences between VB.Net and C# and a lot of places I've read that the differences are largely syntactical. Do I need to post another question on why people poop on VB.Net? –  HK1 Feb 15 '11 at 1:05
@Job @George I don't appreciate your biased comments. See this: en.wikipedia.org/wiki/… –  HK1 Feb 15 '11 at 4:52

6 Answers 6

up vote 6 down vote accepted

Having done both, I can say a bit about them.

Access is useful for quick and dirty prototyping and experimentation. There's less work involved in setting up a simple database and connect up some forms, versus the .NET/SqlServer way. It's also acceptable, in my view, for very simple database applications, where you can be certain the system will be small and not heavily used. I've gone this route for a couple of little personal projects.

At the opposing end of the debate is a full database (e.g. Sql Server) accessed via a .NET application (web, winforms, wpf, etc). This takes more work to set up, but will be more robust and scalable.

There is some middle ground, which I've not done before: create an access application backed by a Sql Server database. You get the high-scale database with the relative simplicity of Access' forms and reports.

On another note, it is possible to take an existing Access database and upscale it to Sql Server without too much trouble. Again, not something I've done, but the option is there.

In the end, you should decide if the tradeoff in scalability is worth the quick start, or if the Access setup is all that you will need.

EDIT: another point, regarding languages. If you're heavily against using VB in any way or form, go the .NET route. In Access, you'll be coding in VBA, a relative to VB, but without the .NET framework.

share|improve this answer
it is possible to take an existing Access database and upscale it to Sql Server It's also possible to cross New York state on your knees, I wouldn't advise it either though. All forms / reports need to be completely re-written. If you use access as a front end over a SQL Db, you loose all the UI goodness that made Forms & Reports so easy to use when Access was holding the data. Reason being the Db engines couldn't work much more differently from each other. It is possible to write large stable apps in Access, but you really need to know what you're doing, and be able to exploit some (cont) –  Binary Worrier Jun 11 '12 at 15:16
. . . undocumented features of Access to do so. IMHO (from hard experience) stay away from Access, I cannot stress this enough. –  Binary Worrier Jun 11 '12 at 15:18

Dot Net advantages:

  • It can use MS-Access as a database as well as other databases. This makes the solution cost less if you care about the cost and also about solution scalability.

  • Dot net works with many fine 3rd party tools that allows you to build a better GUI than MS-Access does. 3rd party components are available for many regular and special use

  • It offers better editor

  • It uses OO languages (C#, VB, etc.) with very powerful .NET classes - It provides for better exception management.

  • Data and code are separate

MS-Access Advantages

  • Has built in report generator (found only on VS Professional Edition)

  • Easy to deploy. Does not required .NET framework (In .Net you need to be careful how you do this)

  • Has many solutions already built for it

  • Easy to code it to do emails and printing of labels (not as easy with .NET)

  • Does a good job for simple applications where the user can manage data directly even without coding

  • Provides OLAP reporting out-of-the-box

MS Access Disadvantages:

  • Costs money

  • MS-Access security is not all that powerful (as I hear - Not sure aobut that).

  • Ms-Access forces you to work with VBA - Not a full OO language

  • Has basic Data Grid control as well as other simple controls only. It is not possible to build advanced custom controls.

  • Code and data exist together in one file

  • May not be easy to provide code sharing amongst developers

  • Not a good choice for web sites of many users

  • Does not provide full text search (as in SQL Server for example)

  • COM based

share|improve this answer

I have had the opportunity to write forms applications with MS Access and to write similar applications with C# and Winforms.

MS Access makes it easy to build something that works, right out of the box.

Winforms makes it manageable to build a scalable enterprise solution.

Don't mix the two.

share|improve this answer

I was hired a while ago in a company which uses Access xp with a SQL server database backend, and I've got to tell you, the argument of scalability is inmediately seen with this application.

While you can setup a form or report really quickly with access, it gives you no control over threading, chokes up with too much data to process, and its kind of lacking in the controls department.

So unless it's only a couple of inexperienced computer users that are going to use the app, I'd suggest you avoid access at all cost.

share|improve this answer

I personally would choose .net over MS Access, even for prototypes.

The reason for this is simple. A company I used to work for once asked a colleague of mine to prototype something in MS Access, on the understanding that it would be upgraded later to C#/Java (management were debating either way).

That never happened. Management decided in the name of expediency that the MS Access solution worked, so why fix it? "We have a working database, now why can't you do X on top?" X in this case being fix the concurrent access problems and various other kludges.

Unfortunately I've had the misfortunate to have some managers for whom a database is a database, now why can't you build on it? Other gems include "plugin architecture", so "you write that in Java, he writes that in Java, then they work together"...

As a result, I now refuse to touch any VBA/Macros/Access stuff. Ever. I'm not trying to be awkward/anti-management - it's a sensible business decision. If we're going to build a multi-user database system, let's do it on the right platform, from the start and not waste time and money persuading a system that isn't designed for that purpose to play nicely.

share|improve this answer
I understand your argument, though it's more the fault of given organisations not understanding the concept of prototyping. –  Orbling Feb 15 '11 at 0:51
The prototype must have been built too well. They should have made it buggy. –  HK1 Feb 15 '11 at 1:09

I have been developing MS-Access applications since ver 1.0 and programming in various versions of Basic for 10 years prior to that. 20 years ago there was a big push, in Canada at least, for the government to purchase seats at Computer Schools. Everyone and their dog took these courses for the dream of big money and ample opportunities. Unfortunately to be a programmer takes a certain type of person. Many of these people who took the courses couldn't hack the course and/or couldn't hack it once they got into the real world. Some of them gravitated to MS-Access. If I had a dime for every Access database developed by one of these inexperienced people I had to overhaul. This has given MS-Access a bad name. Is Access meant for everything, no of course not. In the hands of a capable and experienced developer, it is powerful. I work mostly at banks and insurance companies. When these people want a new application, if they go through their IT departments, it can take months, if not years to get something developed. Put the same request in the hands of an experienced MS-Access developer and it make take a few days or weeks. The reason for the difference is A) IT department red tape and B) all these programmers they trained who don't really like what they are doing, don't do it very well, but do the bare minimum to hold on. As long as they are in the abundant structure of an IT department and spoon fed spec sheets, they can survive. Real programmers can walk up to a client, gather specs on their own, innovate, dream up the most elegant and flexible solution for any size project and then develop it all on their own from start to finish. At the very least, I think MS-Access in the hands of a seasoned developer still has a place in prototyping a solution rapidly to then be handed off to IT for conversion. In many cases portions of VBA code can be cut and pasted into a .NET solution.

share|improve this answer
