EF6代码首先:更新数据库上的登录失败 [英] EF6 Code First: Login Failing on update-database

查看:845
本文介绍了EF6代码首先:更新数据库上的登录失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在EF6代码第一个数据库上执行一个更新数据库。我所做的一切就是构建我的模型和数据文本,运行enable-migrations并进行了一个Add-migration InitialCreate。这一切都很好。



但是更新数据库以两种不同的方式失败。



一段时间我有它的工作,但它正在c:\Users\下创建数据库文件(即MDF和日志文件)。我不想要他们在那里我想要在我建立的MVC网站的App_Data文件夹中(数据库模式位于一个单独的类库DLL中,因为MVC应用程序和控制台应用程序中的一些数据导入和按摩功能需要访问)。



我尝试通过调整连接字符串来更改数据库文件的位置,但是我的更改被忽略(即,数据库文件在c: \\ Users\)或者我遇到第二个错误,无法打开数据库...请求的登录... blah blah blah。然而,我可以在SSMS中打开数据库,我的Windows用户帐户是数据库的所有者。



为了有趣,我尝试从SSMS中删除和创建数据库。这很好...但是update-database命令>> still<<无法登录。



解决这个乱码的任何帮助将不胜感激!



我的构造函数数据文本:

  public CampaignDbContext()
:base(Council2015,throwIfV1Schema:false)
{
Database.SetInitializer< CampaignDbContext>(null);
}

类库中的连接字符串app.config:

 < connectionStrings> 
< add name =Council2015connectionString =Data Source =(LocalDb)\v11.0; AttachDbFilename = E:\\Programming\\Council2015\\Council2015\\ App_Data\\Council2015.mdf; Integrated Security = True; MultipleActiveResultSets = True; App = EntityFrameworkproviderName =System.Data.SqlClient/>
< / connectionStrings>

update-database抛出的最新异常:

 应用显式迁移:[201503180506326_InitialCreate]。 
应用显式迁移:201503180506326_InitialCreate。
System.Data.SqlClient.SqlException(0x80131904):无法打开登录请求的数据库Council2015。登录失败。
用户'KENSEI\Mark'登录失败。
在System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject,UInt32 waitForMultipleObjectsTimeout,Boolean allowCreate,Boolean onlyOneCheckConnection,DbConnectionOptions userOptions,DbConnectionInternal& connection)
...
无法打开数据库Council2015 登录要求。登录失败。
用户'KENSEI\Mark'登录失败。

附加信息



我有一些我不明白连接字符串的东西。如果给连接字符串一个新的名称(例如,Council2015a),并更改CampaignDbContext中的相应构造函数参数,我可以使update-database工作。但是它创建一个新的数据库 - 在c:\Users\下,我不想要它 - 而不是附加到现有的数据库文件。



此外,如果您删除数据库文件,或移动它们(并更新附件文件参数),则再次发生相同的登录失败。



所以有些地方记得以前创建的数据库和拒绝放弃。



这是全部反直觉的(包括为什么数据库以连接中的name参数命名字符串)

解决方案

我偶然发现了基本问题的答案 - 如何将数据库创建到您想要的位置 - - 这似乎已经解决了我遇到的其他问题。



使用一个看起来像你希望看到的连接字符串:

 < add name =Council2015connectionString =Server =(LocalDB)\v11.0;集成Secu rity = true; AttachDbFileName = E:\Programming\Council2015\Council2015\App_Data\Council2015.mdfproviderName =System.Data.SqlClient/> 

但是当您运行update-database(执行任何添加 - 迁移调用后,您需要做) 确保通过update-database命令找到连接字符串。



这听起来应该会自动发生。而且,如果您在启动项目中为您的解决方案创建数据库。因为这是update-database在默认情况下查找连接字符串的地方。



在我的例子中,我在类库项目中定义数据类,以便我可以使用它多个应用项目。所以当我在类库项目的上下文中运行它时,update-database在连接字符串的错误位置。



在包管理器控制台中选择类库作为默认项目不会,尽管您(和我)可能会认为,通知更新数据库的搜索过程对于连接字符串。



而是明确指定启动项目:

  update-database -StartUpProjectName<类库项目名称,在我的情况下> 

和瞧!



为什么无法找到正确的连接字符串 - 由于我在类库项目中使用的id名称甚至没有出现在我的解决方案的启动项目中的连接字符串列表中 - 应该导致用户登录失败错误...好吧,这超出了我:)。还有一个糟糕的软件设计的例子,IMHO。


I am trying to do an update-database on an EF6 code first database. All I've done is build my models and the datacontext, run enable-migrations and did an add-migration InitialCreate. That all worked well.

But the update-database is failing in two different ways.

For a while I had it working, but it was creating the database files (i.e., the MDF and log files) under c:\Users\. I don't want them there. I want them in the App_Data folder of an MVC website I'm building (the database schema is in a separate class library DLL because it needs to be accessible to both the MVC app and some data import and massaging stuff in a console app).

I tried to change the location of the database files by tweaking the connection string, but my changes were either ignored (i.e., the database files keep being created at c:\Users\) or I ran into the second error, "Cannot open database ... requested by the login...blah blah blah". Yet I could open the database in SSMS, and my Windows user account is the owner of the database.

For fun I tried deleting and creating the database from within SSMS. That went fine...but the update-database command >>still<< fails to log in.

Any help in unraveling this mess would be much appreciated!

The constructor for my datacontext:

public CampaignDbContext()
    : base( "Council2015", throwIfV1Schema: false )
{
    Database.SetInitializer<CampaignDbContext>( null );
}

The connection string in the class library app.config:

<connectionStrings>
    <add name="Council2015" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=E:\\Programming\\Council2015\\Council2015\\App_Data\\Council2015.mdf;Integrated Security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient"/>
</connectionStrings>

The most recent exception thrown by update-database:

Applying explicit migrations: [201503180506326_InitialCreate].
Applying explicit migration: 201503180506326_InitialCreate.
System.Data.SqlClient.SqlException (0x80131904): Cannot open database "Council2015" requested by the login. The login failed.
Login failed for user 'KENSEI\Mark'.
   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
...
Cannot open database "Council2015" requested by the login. The login failed.
Login failed for user 'KENSEI\Mark'.

Additional Info:

There's something I obviously don't understand about connection strings. I can get update-database to work if I give the connection string a new name (e.g., Council2015a) and change the corresponding constructor parameter in CampaignDbContext. But it creates a new database -- under c:\Users\, where I don't want it -- instead of attaching to the existing database file.

Moreover, if you delete the database files, or move them (and update the attach file parameter), once again the same login failure occurs.

So something somewhere is remembering the previously-created databases, and "refusing" to let go.

This is all massively counter-intuitive (including why the database is being named after the name parameter in the connection string).

解决方案

I stumbled across the answer to the basic problem -- how to get the database created where you want it -- which appears to have solved the other issues I was encountering.

Use a connection string that looks like you would expect it to have to look:

<add name="Council2015" connectionString="Server=(LocalDB)\v11.0; Integrated Security=true; AttachDbFileName=E:\Programming\Council2015\Council2015\App_Data\Council2015.mdf" providerName="System.Data.SqlClient"/>

But when you run update-database (after doing whatever add-migration calls you need to do), make sure the connection string will be found by the update-database command.

That sounds like it should happen automatically. And it does, if you're creating your database in the startup project for your solution. Because that's where update-database looks for connection strings, by default.

In my case I was defining the data classes in a class library project so that I could use it in multiple application projects. So update-database was looking in the wrong place for connection strings when I ran it within the "context" of the class library project.

Selecting the class library as the "Default project" in the Package Manager Console doesn't, despite what you (and I) might think, inform update-database's search process for connection strings.

Instead, specify the startup project explicitly:

update-database -StartUpProjectName "<class library project name, in my case>"

and voila!

Now as to why a failure to locate the correct connection string -- since the id name I was using in the class library project didn't even appear in the list of connection strings in my solution's startup project -- should have resulted in a "user login failure" error...well, that's beyond me :). And an example of lousy software design, IMHO.

这篇关于EF6代码首先:更新数据库上的登录失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆