Question

A simple question: Is it possible to use C# instead of VBA for MS Access? Can I extend Access applications with windows forms and (or) WPF? Would such a scenario make sense?

Answer 1

Yes, you can write a GUI app in C#, then have MSAccess button (or menu) clicks shell out to the C# app, passing context information on the command line (e.g. Database name, form to open, ID of record, etc).

Alternatively, you can expose a COM interface to your application, so you can use CreateObject to create forms or access other functionality.

You’ll find it very hard to go back the other way, to get access to your MSAccess forms & reports from the C# application, but it can be done using COM, or Windows Sockets).

You can of course just write a C# GUI application with the MSAccess database in the back end, and not use any MSAccess forms (NB If can and do decide not to use any aspects of MSAccess GUI, then I’d strongly recommend using a different database entirely such as SQL Lite or SQL Express).

Hope this helps.

Update In answer to Why would anybody do any of that? What’s the point?

MsAccess database scale dreadfully. I’ve seen well written Access app suffer corruption and data integrity issues with 4 or 5 users. Granted network speed and stability has an effect, but really the problem is access (SqlExpress apps scale better with worse networks). See Limitations of MsAccess

From How scalable is MS Access

Access doesn’t really have a place in
any significant database project. It
is basically aimed at the home market
for people who want to be able to
store info for home use without having
to learn advanced Excel to do it

From an Inform IT article, where they spend much of the article telling you why you should use MsAccess, they add (this emphasis is mine)

• Scalability. Access doesn’t handle
  very large databases easily.
  Generally speaking, the larger the
  database, the more carefully the
  Access application has to be
  designed.
• Networking. Although Access is a
  multiuser database with built-in
  record locking and other
  transactional features, it doesn’t
  work well over a network

“it doesn’t work well over a network” Really dude? In this day and age – with distributed computing the next big thing – what the hell good is that?
So basically, if only one user on one computer needs to use the app, then that’s ok, but if there’s a chance you need to roll this out to multiple users, why spend the time and effort building it in Access, to roll it out you’d need to re-build the app have and a real RDBMS at the back end.

Really you’re better off not using Access in the first place unless of course you’re the only person in the world and you have the only computer 🙂