Tutorial :Does MS Access deserve to be learned?


It comes with Office, it is a "medium good" database, it has more than 800 questions here until today, but I never paid attention to it.

I'm losing something interesting?

I am talking about MS-Access as an IDE for rapid prototyping (or something similar), not about MS-Access as a database only.


One of the strengths of Access is that it's easy to pick up and learn, and you can easily navigate the data in a smallish database. However, SQL Server Express and VB.net are equivalently easy to learn and may offer better long term job skills. Given the choice, I'd recommend the latter.


MS Access is great for:

  • prototyping databases and database frontends
  • creating internal, department solutions based on databases without any formal design, written specification etc. In all environments where is a quick need and a lot of ideas how something should be done, but only you can do it ;-) It's really quick and effective, but if you want to avoid any issues it's a good idea to spend some time experimenting with MS Access to learn its strong and weak sides. Like all other technologies - it has its own logic and has to be understand properly
  • analyzing data and general data processing tasks
  • export/import data from/to MS Access and other possible database engines which can be linked to MS Access tables via ODBC

It's also quite easy to learn and you can gain new knowledge very quickly. I'm sure it can help you very much in daily work. It's worth learning definitely if you're working with database design and development or processing/analyzing of any data (like financial data etc.). In my honest opinion MS Access is one of the most misunderstand and powerful (at the same time) tools, which helps many developers or analysts a lot, but only if they spent some time studying the logic behind MS Access.

I can recommend you to make a short romance with MS Access and then see... If you can use it somewhere. It's very possible that you'll be surprised. It's also possible that you will enhance your overall skills on efficient database design by working with MS Access. A lot of quite complicated and advanced database based systems were started as a home-made prototypes or department-level supporting tools. If you don't want to be disappointed don't require MS Access to be "easier" Visual C# or something - MS Access is database development tool, not an IDE for typical programmers.


I can't really figure out what you're trying to ask but I use Access on a daily basis and it is great for quickly loading and playing with data. Using it for a long term solution is probably not a great idea.


For a front end, it's a fantastic RAD tool. For a backend, it's the tool you use when you can't get a database service:) But SQL Express and SQL lite are free use them as your backend when you can. If MS wants it to stay relevant though they need to move it to .net instead of basing it off VB6/COM. MS did a pretty bangup job of killing VB and I think it will get harder and harder to convince people to invest in learning a dead (dying?) language.

It's also pretty darn useful for reporting analysts who just need to slice and dice data:)


For rapid prototyping, Access is hard to beat. But...

A lot of the development work I've encountered at as a consultant revolves around ripping out and replacing Access databases that are:

  • Inconsistent
  • Unreliable
  • Unmanaged

If you're a developer, you might get work translating Access into something more manageable, which might be a plus. But most of the time, Access is used as a solution for the more computer savvy elements of a company to put together ad-hoc data solutions without IT intervention or expensive projects for little business gain.


More than anything else, Access is good to learn because of the following:

It's so easy to understand and use, that non-IT folks in your organization will decide to build business critical applications around it and expect you to maintain it because there is no budget to upgrade to a more Enterprise-ready database.

As a developer, you may never use it for anything more than rapid prototyping or other simplistic tasks, but to support the business, it is worth the time you will spend.


The form editor in MS Access is quite well done. They have good support for rendering reports, and stand as a good introduction to report generation. It's not as good as Crystal Reports or Jasper, but it's quite nicely integrated with VBA to allow you to manipulate forms, databases, or even programming variables. You can take it as far as you like.

Overall, I would say it's very worth looking at if you're not familiar with programming UI forms, or defining reports.


Here is one other scenario where I loves me some access--it is a great ginsu-style tool for mating up disparate data into a single format as it can talk to nearly everything, is pretty easy to use and is capable of doing some internal scripting and logic if you need anything that fancy. On the other hand, it can behave like a real database enough that you don't mind writing batch import code against it. Most of our data importing stuff ends up patching through access if things get sufficiently complex.


Access is a terrible database, but it's a fine data manipulator. Ms-Access can read from and write to all sorts of data sources. So while I prefer Postgres, SQL Server, DB2, etc., I find Access to be of use from time to time when I need to move data around from one source to another.


Access is perfectly suitable for a very large number of projects and aside from VBA which is too complicated for knowledge workers and too mind numbing for hobbyists and up, Access fills a void that few other "out of the box" applications do.

Plus there's a very good upgrade path to SQL Express if need be. And as Alan mentioned, Access is a very useful tool for connecting to any kind of OLEDB/ODBC data source to work with it in familiar ways. Try connecting Access to SharePoint if you ever need to do any kind of batch maintenance and you'll be glad you did.

Oh, I should also mention that I would never personally touch Access except for the last point. :)


If you are new to databases and SQL, the query builder is a useful tool to learn SQL with. It allows you to "draw" your query and then look at the generated SQL to see what it is doing. Beyond that, it is a bit limited for enterprise use!


I work with access every day but it is limited. Unless you can guarantee your RAD style prototypes are just going to be that - prototypes. Stay well clear and use .NET with SQLServerExpress.

Too often I've worked at origanisations where an access application that server 5 members is now creaking under the scale of a 100+ user base. Things are best done properly.


Yeah, everyone starts by saying nice things about Access, but as you read through their posts you can notice no one actually wants to use it. If you HAVE to learn with Access and there's no way around it, learn it. If you have a choice, I suggest you go with something that's used more frequently these days.


I would avoid it unless I had to. It offers less than SQL Server Express and you can use full-blown reporting services with the developer version of SQL Server (to prototype). I think Expression Blend and WPF is a much better UI prototyping environment.



Download the latest available free versions of Visual Studio and SQL Server (currently both 2008). Open a C# (or VB.NET) Windows Forms project. Use the GUI designer to create a database, a connection and some tables in SQL Server. Use another GUI designer to create a dialog with controls bound to columns in the tables you just created. Enter data and navigate the records. All this without writing any code as such. If this sounds complicated, get the book Head First C#: the first chapter tells you how to do all the above. The experience to this point will be much like it would be in Access, IMO.

So what does Access offer that Visual Studio does not? I think the answer is subforms.

In Access you can create what is calls a 'relationship' (or 'relation') between two tables, use the query builder tool thing create a query joining those two tables and the form designer to create a subform. No doubt you can do this in Visual Studio but I suspect it is easier in Access because its forms work more like reports than dialogs in any other forms-based development product. Very clever.

Professional software engineers in the Microsoft ecosphere prefer Visual Studio to Access forms and SQL Server to the Access database engine (formerly known as Jet). The free version of Visual Studio and SQL Server are more powerful than the Access equivalent tools. The skills you will acquire in TSQL and CLR language of choice (C# is most popular), ADO.NET, LINQ, etc will be IMO more transferable and less niche than learning ACE/Jet SQL, VBA, COM-based data access technology of choice (DAO is most popular), the Access object model, , etc. And as a developer you have to pay to licence Access :(

If you aspire to be a software engineer in the Microsoft ecosphere then avoid Access and take a look at Visual Studio and SQL Server instead.

EDIT: I've received two down-votes (net), and from people I consider to be Access experts, so it's time for a retraction: I was obviously wrong about what I said about subforms. To paraphrase Spinal tap, subform functionality walks that fine line between clever and stupid. I was seemingly wrong about subforms being clever. They must offer no material advantage.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »