Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

entity framework looking at wrong database

VS2013 WebAPI 2.x with Repository has suddenly begin to look for data migrations to happen on a database instance other than the one it has been working with for the past 3 months - EF version 6

I have SQL Server 2012 (v11.0.2218.0) as ron-hp\localdb - this has accepted 12 migrations with add-migration/update-database commands for 3 months

As of yesterday: going to update-database yields message that

PM> update-database -verbose 
Using StartUp project 'PartyPoochesClient'.
Using NuGet project 'PartyPooches.Repository'.
Specify the '-Verbose' flag to view the SQL statements being applied to the target database.
Target database is: 'PartyPooches.Repository.Entities.PartyPoochesContext' (***DataSource: (localdb)\v12.0,*** Provider: System.Data.SqlClient, Origin: Convention).

I have never had an instance of v12.0 and only as of yesterday's migration / update-database attempt PM is expecting to see a (localdb)\v12.0 to accept the update. Any code search entire solution for a (localdb)\v12.0 yields nothing. As expected it times out not able to locate such an instance with SQL Server error 50, the DB, which the project created with CodeFirst, has almost 12 Migration updates to the ron-hp\localdb instance without issue.

The code:

internal sealed class Configuration : DbMigrationsConfiguration<PartyPooches.Repository.Entities.PartyPoochesContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = false;
        ContextKey = "PartyPooches.Repository.Entities.PartyPoochesContext";
    }

    protected override void Seed(PartyPooches.Repository.Entities.PartyPoochesContext context)

The config:

<entityFramework>
  <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
    <parameters>
      <parameter value="Data Source=ron-hp\localdb;Initial Catalog=PartyPooches.Repository.PartyPoochesContext; user=xxxxx;password=xxxxx; MultipleActiveResultSets=True;App=EntityFramework"/>
    </parameters>
  </defaultConnectionFactory>
  <providers>
    <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer"/>
  </providers>
</entityFramework>

The DbContext

public class PartyPoochesContext : DbContext, IDisposable
{
    public DbSet<Dog> Dogs { get; set; }
    public DbSet<Handler> Handlers { get; set; }
    public DbSet<Skill> Skills { get; set; }
    public DbSet<DogType> DogTypes { get; set; }
    public DbSet<Schedule> Schedules { get; set; }
    public DbSet<Appointment> Appointments { get; set; }
    public DbSet<PaymentType> PaymentTypes { get; set; }
    public DbSet<Customer> Customers { get; set; }

The settings above have seen this SQL Server 2012 instance shown for 3 months.

No changes made to settings, but a recent entity change change has been implemented for a minor database update which is now looking to a non-existence instance of SQL Server. Flawless for 3 months until yesterday. Unable to locate any internet-based information dealing with this. Acts like some NuGet package slipped something in but not certain of that.

like image 275
rondan Avatar asked Mar 17 '23 00:03

rondan


1 Answers

The key to the source of your issue is here: Origin: Convention. the <parameter value="DataSource=..." for Entity Framework is not actually the project's database connection string. It is the parameter being supplied to your application's ConnectionFactory when the app creates a new DbContext. However, any other connections outside Entity Framework when the app is running, or Entity Framework itself when the app is not running (for example, migrations) expect a traditional ConnectionString key in the web.config.

When you attempt to perform an update-database and there is no ConnectionString value present, Entity Framework uses convention to decide upon a connection string to use. This convention is based on many factors, including the version of software installed on your PC. If you only have SQL LocalDb 2012 installed on your machine (the standard with earlier releases of Visual Studio 2013) then the actual localdb path would be (localdb)\v11.0 by default convention. This actually stores your database in the folder %localappdata%\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0 on your disk drive.

If any application on your machine updates your system to SQL LocalDb 2014, the convention changes to (localdb)\v12.0, and new databases are assumed to be put in %localappdata%\Microsoft\Microsoft SQL Server Local DB\Instances\v12.0.

Ultimately, you should provide a more complete DataSource value than localdb, using the specific path you wish to use, (localDb)\v11.0. You also should provide a <ConnectionString> value in your web.config to match your Entity Framework <Parameters> key, to ensure that you are always guaranteed to target the same database in every instance.

Also note, that instead of using the DefaultConnectionFactory, you could instead pass the name of the <ConnectionString> key to the constructor of your DbContext.

like image 166
Claies Avatar answered Mar 20 '23 00:03

Claies