The Self-Taught Programmer

Recipes from real-world experience with asp.net.

Posts Tagged ‘Entity Framework

How To Extend the Timeout Period on an Entity Framework Query

with 3 comments

The Situation:

You have a long running Entity Framework query that often creates a “System.Data.SqlClient.SqlException” with the message “Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.”

A Solution:

As near as I can find, the default timeout for EF queries using the SQL Server 2008 connection provider is 30 seconds. If your query runs longer than that, you are going to get the error above.

If you are using dbContext, the solution to this is to add the following code before your query to set the timeout to a longer value:

((IObjectContextAdapter)Context).ObjectContext.CommandTimeout = 180;

Of course, you can use any number of seconds you need. This line of code moves you down from dbContext to the underlying ObjectContext to make the change.

I’m not sure why Microsoft didn’t keep the simpler syntax from the older version of ObjectContext for dbContext. If you are using ObjectContext, you can do without the adapter, like this:

this.Context.CommandTimeout = 180;

To keep from having to put this code in every query, you could call it when you instantiate the dbContext. You may find it helpful to keep the default timeout for most queries and catch the error to give you insight into database problems.

Advertisements

Written by Jim McMullen

July 28, 2013 at 3:16 pm

Posted in How-To

Tagged with , ,

How to Add a New Table to an Existing Database via EF Code-First Migrations

leave a comment »

The Situation:

You have been using Entity Framework code-first migrations with an existing database. Making changes to an existing table, such as adding a new field, go smoothly, and the database is updated correctly when you run an “Update-database” command. However, when you create an entirely new entity in your model and run “Update-database”, the new table doesn’t get added to your database. You get the “No pending code-based migrations” message.

A Solution:

I spent some time today researching this on StackOverflow and other forums and came up with no solution. It wasn’t until I started to think through the details of the process that EF migrations goes through that I found the answer.

EF migrations use a Configuration.cs file, which specifies an EF dbContext to use in communicating with the database. The context file lists all the entities that it manages. Therefore, you must add the new entity to the context file!

Once you add it to the context, EF migrations can “see” it and add it to the database.

Written by Jim McMullen

February 19, 2013 at 3:41 pm

Posted in How-To

Tagged with

How to Enable and Use EF Code-First Migrations for Multiple Contexts

with 4 comments

The Situation

You want to use Entity Frameworks code-first migrations to push model changes to the database, but you have multiple databases and contexts in your model. When you try to run Enable-Migrations for the second context, you get an error that looks like this:

Migrations have already been enabled in project 'Project1'. To overwrite the 
existing migrations configuration, use the -Force parameter.

If you go ahead and use the “-force” parameter, it will overwrite your Configuration.cs file for the 1st context, which isn’t what you want.

A Solution

The work-around for this is to rename the Configuration.cs file that is generated on the first run and to give it its own namespace. Here are the steps I took:

1) I keep my data access code separate from my UI by putting it in a separate project and referencing it from my UI project. To make Enable-Migrations work properly, I had to temporarily make my data access project my startup project by right-clicking on the project in the Solution Explorer and clicking on “Set as startup project”. (You won’t need to do this if your contexts are in the same project as the rest of your application.)

2) In the Package Manager Console, run this command:

Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NameOfFirstContext

3) A Migrations folder will be added to your project with a Configuration.cs file in it. Rename the file. Maybe something like “ConfigurationContext1.cs”.

4) Now open the Configuration.cs file and change the namespace. I added the name of the context to the namespace.

This is important. Giving each configuration file its own namespace will make sure that migrations are only applied to the correct context. If you don’t do this, the Update-Database command will look at ALL the pending migrations and try to apply them to the current context. This could result in an error (such as “Unable to generate an explicit migration because the following explicit migrations are pending:“)¬†or tables might be added to/deleted from the wrong context/database.

5) In the Package Manager Console, run the same command for for the next context:

Enable-Migrations -EnableAutomaticMigrations -ContextTypeName NameOfSecondContext

6) Repeat the above steps for each context that you need to enable migrations.

7) Rename the new Configuration.cs file, maybe “ConfigurationContext2.cs”.

To update the database with changes to your model, simply specify the configuration file to use for the update like this:

Update-Database -ConfigurationTypeName ConfigurationContext2

Written by Jim McMullen

February 14, 2013 at 11:14 am

Posted in How-To

Tagged with

Entity Framework: Repository or Not Repository?

leave a comment »

On the heels of the demise of the commercial version of EntitySpaces, I am delving into Microsoft’s Entity Framework. I need to implement it in a big project to replace a much more manual Data Access Layer.

So I’ve done a ton of reading on it (and played with it some, too), and the common wisdom is to use the Repository Pattern to implement it. The main reason seems to be to maintain a separation of concerns — so that the persistence layer isn’t directly used/referenced from the UI. In turn, this seems to be important so that you can change the underlying data structure without changing the UI very much.

At first, this seems to add a layer of complexity to an application that doesn’t seem to be necessary — I never used this pattern with EntitySpaces (although I could have), and indeed, the ES developers recommended against it. Entity Framework uses the dbcontext as its own repository/unit of work pattern, so why add a whole other level of abstraction to it? Adding complexity will surely slow down development, and speeding things up is my primary motivation for using an ORM framework.

There is a terrific case made for NOT using repositories by Oren Eini (aka Ayende Rahien), a contributor to the NHibernate open-source ORM framework. His post can be found here.

Will I ever actually change the database layer?

As I said, this doesn’t seem to be necessary – I don’t believe I will change the underlying database from SQL Server to Oracle or some other database. Even if I did, Entity Framework can work with many different databases.

I suppose there is a possibility that it could change to a web service implementation. I don’t know why the project would change like that, but it could if the need arose. In this case, repositories would insulate the UI from that change. I am implementing EF using POCOs, so those could be kept and reused even with web services.

But What If I Change the UI?

But after thinking about it for a while, the most important reason to maintain separation of concerns in my project is that I don’t know how the UI layer will change. I can already see the possibility of creating several UIs – Web, mobile, and public web services. Aha! If I use repositories, I can develop as many UIs as I want using the same data access layer. Or almost the same data access layer — I am certain I would have to add custom methods to my repositories for each UI.

But can I still create multiple UIs if I don’t use repositories — using EF directly? Yes, of course I can. On the downside, there will be some duplication of code. Conversely, the data access will be tailored directly to my UI needs.

So what’s the right answer?

Guess what, despite the legions of fanatics that will tell you there is only one “right” way to do it, either way will work.

For speed’s sake, I strongly considered going without repositories, but I have decided to use them based on the multiple examples of their effectiveness and my uncertainty about future UI development for my project.

Written by Jim McMullen

February 1, 2013 at 10:32 pm

Posted in How-To

Tagged with