Using MS Access as a .NET Application Backend [closed]

Question

I am the lone .NET developer in an non-IT organization. I've been asked to develo ae .NET application using Microsoft Access as the back-end (existing DB).

I don't know where to start.

Since I'm developing by myself, what should I keep in mind to avoid during development? What situations does only a lone developer face?

Please include Microsoft Access specific advice in your answer, since that is germane to the question.

Answer 1

Where to start?

1. Choose a development environment (I would suggest Visual Studio 2008 Express or Professional, depending on the budget and the need for features of the Professional version)
2. Even for one single developer: choose a Version control system !!!! (Subversion has only little administrative overhead, fine for one developer)
3. Choose a .NET Framework version (3.5 is fine unless your application has to run on Win2K; for Win2K use .NET 2.0)
4. Choose a mature programming language (C# or VB.NET, what you or your boss likes best)
5. Choose a GUI technology (for a single developer, I would suggest using WinForms, unless you are going to write a Web application or a command line utility)
6. Choose a mature DB access technology (ADO.NET works for a lot of things, unless you have very high performance requirements that are better dealt with old ADO/OleDB or DAO)
7. EDIT: use Google to find some entry examples according to the choosen technology, or buy yourself a book. For example, here is one for C# using OLE DB to access a MS Access DB. This Access site is a good starting point, too.
8. EDIT2: make yourself familiar with "Microsoft Access" (the Office Application). Not because you are going to use it like a typical user, but you will probably need it for administrative purposes. And the VBA & SQL documentation included will be sometimes helpful, even if you code with C# or VB.NET

9. EDIT3: for reporting purposes, choose a reporting technology. There are plenty of possibilites here, depending on your needs, your skills and/or budget, for example

   • Plain ASCII or CSV reports (coded by hand)
   • HTML or XML reports
   • using Excel as reporting engine
   • using a PDF library like Report.NET
   • using a third party tool like Crystal Reports

   You will find a lot of helpful links when you give "report generation .net" to Google, for example this one.

And finally: come back to SO and ask more concrete questions when you come to the point where you have them.

There might be other constraints, depending on what code is already existing in your organization. And I would avoid technologies like F#, WPF or Linq to Entities.