My last post was about LINQ and EF Data Providers, which made me think of this.
I received an email recently asking if I knew of anyone writing an Entity Framework provider for Access.
I don’t happen to know of any.
However there’s a reason.
In the forums, there is a post from July where Danny Simmons explained the hurdles with a possible Access provider:
The OLE-DB ado.net provider has not been extended to support the entity framework, and we do not currently have plans to do so in our first release. Further, this would be a fairly difficult effort because OLE-DB doesn’t provide enough information in general to translate CQTs (canonical query trees–the entity framework intermediate query representation) to a particular back-end query syntax. So, while it would be possible to write an Access provider which would translate from CQTs to the particular query syntax that access uses, we don’t have an access-specific ado.net provider, and the general OLE-DB provider would not be able to do the job.
We have done some internal prototyping of how Access and the entity framework might work great together in the long-run, but those were just explorations, and we will not have direct support for Access in the first release of the entity framework.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
One thought on “Speaking of Ent. Framework providers – what about Access/OleDB?”
Hi, Julie,Considering the technical issues with CQT and the Jet query processor and the amount of baggage associated with Jet*.dlls as a whole, I don’t think it makes business sense to create an Access provider. Plus Jet is deprecated except for Office Access.Last I heard, a provider for SQL Server Compact Edition was in the works. SSCE 3.5 installs easily and it’s T-SQL-like query language should support most of the CQTs. However, I think LINQ to SQL would be a better RAD fit for SSCE because it consumes fewer resources.Cheers,–rj