1

Environment:

  • Windows 8.1
  • Visual Studio 2013
  • Project type: ASP.NET MVC
  • Debugging in IIS Express.
  • DotNet: 4.5
  • Database: SQLExpress 2012
  • EntityFramework 5

When I run my solution (F5), in Debug or Release configuration, I can manipulate data through EF with no issues; data changes persist between views. If I query the database in Management Studio however, none of the updates are reflected in it. If I update a record in Management Studio, the changes aren't reflected in my running solution either.

If I then stop and restart, or even just stop and do a build (CTRL, SHIFT, B) in VS, my data in the web application all reverts back to the state matching that of my database through Management Studio.

If I add a trace to the database, I can see reads, but no writes coming through to the db. Additionally, if I stop the SQLExpress service, my pages throw "SQL Server service has been paused/stopped" exceptions. So bizarrely enough, it looks like it's reading from the correct database, but may be writing to a development cache somewhere?

This leads me to think that on every build, a copy of the db is being used for that debug/run session's state.

So the question then becomes, where is this being set, and where is the temp db living? I have scoured my web.config, web.debug.config, web.release.config, but there is no reference to an alternate database.

I have looked in the /App_Data and /bin folders, but there's no extra database there either. I even resorted to watch the filesystem using procmon for any file operations performed by VS with a build, but I couldn't find anything of note (there is tons of data, so may have missed something).

I have a couple of debug statements spitting out the connectionstring being used by EF, and can confirm that it's pointing the the correct SQLExpress instance.

System.Diagnostics.Debug.WriteLine("Conn String: " + ctx.Database.Connection.ConnectionString);

The only other possibility is that EF is suddenly holding a large cache. I doubt this though as I trace the DB frequently and updates generally happen immediately.

This behaviour is relatively new, but don't know exactly when it started. The only significant change was the VS upgrade from 2012 to 2013, but can't be sure it correlates with the upgrade.

Anyway, I'm now at an end of my tether, and would love any suggestions that I could follow.

BlinkyBill
  • 397
  • 2
  • 12

2 Answers2

1

OK, I figured it out. So for anyone else having similar issues, it relates to synchronising EF contexts.

I was declaring my classes with a static context reference to save having to declare it in every method thus:

public class MyClass : Controller
{

    private static MyContext db = new MyContext();

    ...
}

Being static, as you would expect, it's evaluated at start-up, and held in memory.

Adding that to the fact that I was changing properties on my objects retrieved from the static context, but updating to a different context (helper function confusion), all resulted in the confused state I was seeing.

So the moral of the story: Don't use static context references. Declare them as you need them. Double check that you're retrieving and updating to the same context.

BlinkyBill
  • 397
  • 2
  • 12
0

Visual studio installs sqlexpress, normally this is what code first uses. You can use management studio to to connect to the express instance. It's also possible that it's using localdb by default for vs 2013 still optional in 2012.

Mike Beeler
  • 4,081
  • 2
  • 29
  • 44
  • Thanks Mike, As noted, I'm using SqlExpress as my database. That's where the "Static" state is. I had considered localDb, but a) can't find where it's being set, and b) can't find an instance other than the default: (LocalDb)\v11.0. – BlinkyBill Nov 08 '13 at 03:51
  • If you enable migrations and add a property to your model and do an update database with the -verbose switch that should show where ef thinks the database is. – Mike Beeler Nov 08 '13 at 04:06
  • Cracking idea, though I'm not using code first so I don't know that it will help. Note that I've edited the question to add the fact that I've got a couple of debug statements spitting out the EF querystring, which is correct (SQLExpress). – BlinkyBill Nov 08 '13 at 04:20
  • So when you call save changes for your object no exceptions. Do the changes persist across app shutdown and restart, the database explorer should show if there is another instance running failing that I would look in app data for the .mdf file. Same idea modify your model and regenerate the poco objects and see if the new colum shows up in the database. Normally I would use the sql profiler but that's not available for express. Two links to look at http://miniprofiler.com and http://www.paulkiddie.com/2013/03/tracing-all-sql-generated-by-entity-framework/ to get at the generated sql. – Mike Beeler Nov 08 '13 at 04:46
  • Thanks Mike, Any restart/rebuild of the app resets the data. Database explorer shows no other database. As mentioned in my question, appData is empty. Profiler does work with express as detailed in my investigations. – BlinkyBill Nov 08 '13 at 04:59
  • Is there any data in the database that you could use to do a find on an existing object and verify after finding it that the object is being tracked by the database by looking at the .state of the object – Mike Beeler Nov 08 '13 at 05:15
  • Try using objContext.Refresh(RefreshMode.StoreWins, myobj); just after calling savechanges this will force a reload from the database. – Mike Beeler Nov 08 '13 at 05:22