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

Answer 3

You can use C# to control everything in Access but it seems like complete overkill. I would think VBA can handle any/all demands and with VBA you can even create custom functions in Access to do things that would be impossible using just standard built-in Access tools. Again, if you want to use C# to mange Access, yes, you can certainly do that.

Here is a good link to get you started.

http://csharp.net-informations.com/data-providers/csharp-oledb-connection.htm

There are lots of other links at the bottom of that page that should help you with many other things.

Answer 4

Of course you can do that. You can do so many things when you integrate C# and Access. For instance, here is a way to load a GridView from Access.

using System;
using System.Data;
using System.Windows.Forms;
using System.Data.OleDb;

namespace WindowsApplication1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            string connetionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=your .mdb file;";
            string sql = "SELECT * FROM Authors";
            OleDbConnection connection = new OleDbConnection(connetionString);
            OleDbDataAdapter dataadapter = new OleDbDataAdapter(sql, connection);
            DataSet ds = new DataSet();
            connection.Open();
            dataadapter.Fill(ds, "Authors_table");
            connection.Close();
            dataGridView1.DataSource = ds;
            dataGridView1.DataMember = "Authors_table";
        }
    }
}

Take a look at the link below for some more ideas of what can be done with C# and Access.

https://www.codeproject.com/Articles/1060352/Using-Microsoft-Access-Database-In-Csharp-ADO-NET

Although............I have to say, you will probably never get away from VBA. Also, VBA is the low-hanging fruit. It's a whole lot easier to use VBA with Access rather than trying to tame C# to do essentially the same thing that VBA would do for you. Also, VBA is probable a lot more limiting, and C# will be a lot more flexible, in terms of what you can achieve.