You can't use Entity Framework, because it doesn't work with Access databases.
It's possible to use NHibernate with MS Access, although NH doesn't support Access out of the box.
You need NHibernate.JetDriver from NHContrib and here are example settings for the NH config file.
If I recall it correctly, NH Contrib needs to be compiled against the exact NH version you're using, so you probably need to download the source code and compile it by yourself.
As an alternative, you can use one of the many micro-ORMs, for example Stack Overflow's own Dapper.
Dapper is DB agnostic, so it can connect to everything including Access. Quote from the official site:
Will dapper work with my db provider?
Dapper has no DB specific implementation details, it works across all .net ado providers
including sqlite, sqlce, firebird, oracle, MySQL and SQL Server
The disadvantage is that because Dapper is DB agnostic, you have to implement some advanved stuff yourself, like paging.
EDIT:
IMO Dapper is in the "fairly easy to run quickly catagory".
Take a look at this:
(complete demo project here)
using System;
using System.Data.OleDb;
using Dapper;
namespace DapperExample
{
class Program
{
static void Main(string[] args)
{
using (var con = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=test.mdb"))
{
var list = con.Query<Product>("select * from products");
Console.WriteLine("map to a strongly typed list:");
foreach (var item in list)
{
Console.WriteLine(item.ProductNumber + " : " + item.Description);
}
Console.WriteLine();
var list2 = con.Query("select * from products");
Console.WriteLine("map to a list of dynamic objects:");
foreach (var item in list2)
{
Console.WriteLine(item.ProductNumber + " : " + item.Description);
}
Console.ReadLine();
}
}
}
public class Product
{
public string ProductNumber { get; set; }
public string Description { get; set; }
}
}
There are two different queries in this example code.
The first one maps to a strongly typed list, e.g. the result is an IEnumerable<Product>. Of course it needs a Product class that it can map to.
The second query returns an IEnumerable<Dynamic> (>= .NET 4.0) which means that the properties are evaluated on the fly and you don't need to define a class before, but the disadvantage is that you lose type safety (and IntelliSense).
My personal opinion is that the missing type safety is a deal breaker for me (I prefer the first query syntax), but maybe this is something for you.
