MS Access without VBA?

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 :)

Answer 2

Well,

if you do not want to use Acces's VBA (and I guess all related objects like forms, modules, etc), I guess you'd better not use Access at all. Store your data in any 'real' database engine, free or not (SQL Express, MySQL, etc) and build your user interface in your favorite language.