In this forum here , someone mentions that Entity Framework does not work with Access (Jet DB - .mdb). However it seems that there is a provider for Jet DB as described here
Which makes me think that the only thing I need with Entity Framework is to define the follwing before I define the models:
<connectionStrings>
<add name="ProductContext"
providerName="Microsoft.Jet.OLEDB.4.0"
connectionString="Source=C:\mydatabase.mdb;Jet OLEDB:Database
Password=MyDbPassword;"/>
</connectionStrings>
Does anyone know if Entity Framework works fine with Jet DB, I want to make sure it does before I start since my design document depends on this fact.
Thanks
Entity Framework does not support OLEDB connections, so your connection string will not work. It is practically impossible to get Entity Framework to collaborate with MS Access. You will either need to dump the MS Access part of your design, or the Entity Framework part.
The closest you could get using MS Access is using strongly typed datasets and Linq-to-DataSet http://msdn.microsoft.com/en-us/library/bb386977.aspx
Or, considering going with SQL Express instead (it's free) http://www.microsoft.com/sqlserver/en/us/editions/2012-editions/express.aspx
There is a MS Access EF 6.1 provider here
https://jetentityframeworkprovider.codeplex.com/
EDIT
Now the EF provider for Access is hosted on GitHub
https://github.com/bubibubi/JetEntityFrameworkProvider
Related
How to create View (SQL) from Entity Framework in ABP Framework
Not allowed to post comments because of reputation. Just trying to get more information on connecting a database to an Entity Framework, without having to switch to a code-first development style. View selected answer's response (he told the OP to basically do the same thing he was going to do in the DB but with EF, and then added an extra step where EF "...ignores..." the previous instructions...
I want to create tables and design database directly in SQL, and have the csharp library just read/write the table values (kind of like how dapper function where it isnt replacing your database, just working along side of it).
The tutorials don't talk about how to integrate your databases with your project. It either brushes over the subject, ignores it completely, or discusses how to replace it.
I don't want to do any EF migrations (i dont want/need to destroy/create database everytime i decide to run, duplicate, or transfer project). Any and all database back-track (back-up/restore) should be done with and thru SQL (within my work environment).
Just to be clear on exactly what i'm trying to learn:
How does somebody who specializes in database administration (building database schema, managing and monitoring data, and has existing database with data established) connect to project to fetch data (again, specifically referencing Dapper's Query functionality).
I want to integrate and design micro-services, some may share the same database connection or rely on another. But i just simply want to read data in a clean strongly-typed class entity, and maybe deal with insert/update somewhere else if i have to.
I would prefer to use Dapper instead of EF, but ABP is so heavily integrated with EF's design, it's more of a headache to avoid it, than it is to just go along with.
You should be able to map EF under ABP the same way as any other project using DB-first configuration.
The consistent approach I use for EF: (DB-First)
Define entities to match the table/view structure.
Define configuration classes extending EntityTypeConfiguration<TEntity> with the associated ToTable(), HasKey(), and any HasMany/HasRequired/HasOptional for relationships as needed.
In DbContext.OnModelCreating: modelBuilder.Configurations.AddFromAssembly(GetType().Assembly); to load all entity configurations. (assuming DbContext is in the same assembly as the models/configurations Substitute GetType().Assembly to point at the entity assembly.
Turn off Migrations. In DbContext constructor: Database.SetInitializer<MyDbContext>(null);
EF offers a lot more than simply mapping tables to classes. By mapping relationships between entities, EF can help generate optimized queries for retrieving data across those related entities. This can allow you to flatten data structures without returning unnecessary data, replace the need for views, and generally reduce the amount of data coming across the wire from the database to the application server.
Hey I have a unique and troubling situation.
I am working on a project where my team has used a mixture of Enterprise Data Library plus Entity Framework. Obviously this probably not recommended but it is what I'm stuck with. I would like to take a method written using Enterprise Data Library and also take a different method written using Entity Framework, and wrap both of these methods in a single transaction (without requiring Microsoft Distributed Transaction Service). I'm hoping to minimize rewriting code and be able to wrap the two methods in a single transaction just as they are. Is this possible? Thanks.
Using SQL Server 2008 and .NET 4.0
I suppose you want to mix EF and EntLib queries in the same TransactionScope, without using DTC.
Good news: it's possible. If you use exactly the same connection string for EntLib DAAB and EF DbContext, it will work, depending on the versions of EF, EntLib and SQL Server.
So what you have to do is:
check you have the right versions
get the version of your connection string changed by EF and use it instead of yours.
For 1, I have checked these combinations:
SQL Server must be 2008 or older
EntLib 4.1 + EF 5 doesn't work
EntLib 5 + EF 5 works
For 2, to get the connection string changed by EF you have to debug the execution of code that uses an instance of a DbContext. Set a breakpoint and watch or inspect the DbContext Database.Connection.ConnectionString property. That's the EF version of your connection string. Use it for both EF and EntLib and you'll get rid of DTC.
I have a MVC3 website I have been playing with, and the database is quite well populated. I need to change the underlying models, but of course, the standard approach would drop all data. Having the CREATE SQL (so I can ensure all fields/relationships are in line with the models), and the calculated hash (so EF thinks the models match the database) would allow me to manually make changes to the database.
Is there a way to interrogate a DataContext (or some other object) to:
1. Get the SQL it would use to generate the dataschema; and
2. Get the ERM Metadata hash
I have considered some other migration options, but just want to explore this avenue.
Edit: This is EF4.1, and is running against SQL 2008 R2 if that is of any relevance.
Thanks
Andrew
You can do it with EF Migrations. You'd need to upgrade your project to EF 4.3. You'd use the "Update-Database -Script" ps command.
Here is a link to the ASP.Net team blog on it: http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
Pluralsight also has a course on it. They also have a free trial. http://www.pluralsight-training.net/microsoft/Courses/TableOfContents?courseName=efmigrations
I'm using VS 2008 with SP1. I want to use SP in the entity framework. The problem is that my SP returns more than 1 result set. How do I get the multiple result sets? All the online examples are showing single result. Please help me.
Entity Framework unfortunately does not support multiple result sets from stored procedures - not even in the .NET 4 release.
You will need to either rewrite your stored procs, or access them using standard, bare-bones ADO.NET - and ask Microsoft for support for multiple SP result sets in EF 5 !! I'll cast my vote in favor, too!
Related to this question:
Entity Framework - get records in multiple tables using stored procedure
Another SO user reports success with a plugin project, EF Extensions.
As marc_s describes, the feature is not built in to EF... another reason for DBA Developers to shy away from EF, imho.
I am creating a project using Entity Frameworks 4 and self tracking entities. I want to be able to either get the data from a sql server 2008 database or from sql server compact database (with the switch being in the config file). I am using the repository pattern and I will have the self tracking entities sitting in a separate assembly.
Do I need two edmx files? If so, how do I generate only one set of STE's in the separate assembly? Also do I need to generate two context classes as well? I am unsure of the plumbing for all this. Can anyone help?
Darren
I forgot to add that the two databases will be identical and that the compact version is for offline usage.
Just to follow up on this. In the end I had to maintain two separate edmx files, one for sql server and one for compact. The main reason being that compact 3.5 does not support auto identities (as mentioned above by Zeeshan). This in turn led to two context classes. In the context class for sql server compact I had to put code to check for insertions, query the database for the latest id and increment it manually before saving.
Thankfully with the release of compact 4.0 this no longer applies as it supports auto id and you can indeed use just one edmx file.
Darren
You do need the edmx file as long as the schema is exactly the same. just change the connectionstring and everything would work seamlessly. Though i am not sure how u are saying that schema is same when compact edition does not support identity concept and full blown sql server does. So if you are using features specific to sql server that's not available in compact, then you would get runtime errors.