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.
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.
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
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.
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.
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.
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.
