如何为Entity Framework重新创建数据库？

Question

使用Code-First Entity Framework,我的ASP.Net MVC 5项目陷入了糟糕的状态.我不关心丢失数据,我只是想重新开始,重新创建数据库并开始使用Code-First迁移.

目前我处于一种状态,每次尝试更新数据库都会导致抛出异常或收到错误消息.此外,该网站无法正确访问数据库.如何擦除所有迁移,重新创建数据库并从头开始而无需创建新项目？换句话说,我想保留我的代码,但删除数据库.

稍后我还想让部署数据库(Azure上的SQL Server)同步.同样,我不介意丢弃所有数据 - 我只是想让它工作.

请提供任何操作步骤以恢复干净状态.非常感激.

Answer 1

请遵循以下步骤:

1)首先转到Visual Studio中的服务器资源管理器,检查此项目的".mdf"数据连接是否已连接,如果是,请右键单击并删除.

2)转到解决方案资源管理器,单击显示所有文件图标.

3)转到App_Data,右键单击并删除此项目的所有".mdf"文件.

4)右键单击并删除删除迁移文件夹.

5)转到SQL Server Management Studio,确保此项目的DB不存在,否则将其删除.

6)转到Visual Studio中的程序包管理器控制台并键入:

1. Enable-Migrations -Force
2. Add-Migration init
3. Update-Database

7)运行您的应用程序

注意:在步骤6第3部分中,如果出现"无法附加文件..."错误,可能是因为您没有在SQL Server中完全删除数据库文件.

Answer 2

我想补充一点,林的回答是正确的.

如果您不正确地删除了MDF,则必须修复它.将项目中的拧紧连接固定到MDF.简短的回答; 重新创建并正确删除它.

1. 创建一个新的MDF并将其命名为与旧MDF相同,将其放在同一文件夹位置.您可以创建一个新项目并创建一个新的mdf.mdf不必匹配旧表,因为它们将删除它.因此,创建旧文件或将其复制到正确的文件夹.
2. 在服务器资源管理器中打开它[双击解决方案资源管理器中的mdf]
3. 在服务器资源管理器中删除它
4. 从解决方案资源管理器中删除它
5. 运行update-database -force [必要时使用武力]

完成,享受你的新数据库

更新 11/12/14 - 当我进行破坏性数据库更改时,我一直使用它.我发现这是将迁移回滚到原始数据库的好方法:

• 将数据库恢复原状

• 运行正常迁移以将其恢复为当前状态

  1. Update-Database -TargetMigration:0 -force [这会破坏所有表格和所有数据.]
  2. Update-Database -force [必要时使用武力]

Answer 3

这对我有用:

1. 从Visual Studio中的SQL Server对象资源管理器中删除数据库.右键单击并选择"删除".
2. 从文件系统中删除mdf和ldf文件 - 如果它们仍在那里.
3. 重建解决方案.
4. 启动应用程序 - 将重新创建数据库.

Answer 4

虽然这个问题的前提是不关心数据，但有时数据的维护是必不可少的。

如果是这样，我在这里编写了有关如何在数据库已具有同名表时从实体框架噩梦中恢复的步骤列表：如何从实体框架噩梦中恢复 - 数据库已具有同名表

显然......版主认为适合删除我的帖子，所以我将其粘贴到这里：

如何从实体框架噩梦中恢复 - 数据库已具有同名表

描述：如果您像我们一样，当您的团队刚接触 EF 时，您最终会处于无法创建新的本地数据库或无法将更新应用到生产数据库的状态。您想要回到干净的 EF 环境，然后坚持基础知识，但您做不到。如果你让它在生产环境中工作，你就无法创建本地数据库，如果你让它在本地环境中工作，你的生产服务器就会不同步。最后，您不想删除任何生产服务器数据。

症状：无法运行Update-Database，因为它正在尝试运行创建脚本并且数据库已具有同名的表。

错误消息：System.Data.SqlClient.SqlException (0x80131904)：数据库中已存在名为 '' 的对象。

问题背景：EF 根据数据库中名为 dbo.__MigrationHistory 的表了解当前数据库与代码所在位置的比较。当它查看迁移脚本时，它会尝试将上次所在的位置与脚本进行协调。如果不能，它只是尝试按顺序应用它们。这意味着，它会返回到初始创建脚本，如果您查看 UP 命令中的第一部分，它将是发生错误的表的 CreateTable。

要更详细地了解这一点，我建议观看此处引用的两个视频： https: //msdn.microsoft.com/en-us/library/dn481501 (v=vs.113).aspx

解决方案：我们需要做的是欺骗 EF 认为当前数据库是最新的，而不应用这些 CreateTable 命令。同时，我们仍然希望这些命令存在，以便我们可以创建新的本地数据库。

步骤 1：清理生产数据库 首先，备份生产数据库。在 SSMS 中，右键单击数据库，选择“任务 > 导出数据层应用程序...”，然后按照提示操作。打开生产数据库并删除/删除 dbo.__MigrationHistory 表。

步骤 2：本地环境清理 打开您的迁移文件夹并将其删除。我假设如果有必要你可以从 git 取回这一切。

步骤 3：重新创建初始 在包管理器中，运行“Enable-Migrations”（如果您有多个上下文，EF 将提示您使用 -ContextTypeName）。运行“添加迁移初始-详细”。这将创建初始脚本，以根据当前代码从头开始创建数据库。如果您在之前的 Configuration.cs 中有任何种子操作，请将其复制过来。

步骤 4：欺骗 EF 此时，如果我们运行Update-Database，我们将得到原始错误。因此，我们需要欺骗 EF 使其认为它是最新的，而不运行这些命令。因此，进入您刚刚创建的初始迁移中的 Up 方法并将其全部注释掉。

步骤 5：更新数据库 由于在 Up 进程中没有要执行的代码，EF 将创建 dbo.__MigrationHistory 表，其中包含正确的条目，表明它正确运行了此脚本。如果你喜欢就去看看吧。现在，取消注释该代码并保存。如果您想检查 EF 是否认为其是最新的，您可以再次运行Update-Database 。它不会使用所有 CreateTable 命令运行 Up 步骤，因为它认为它已经完成了此操作。

第 6 步：确认 EF 实际上是最新的 如果您有尚未应用迁移的代码，这就是我所做的...

运行“Add-Migration MissingMigrations”这实际上将创建一个空脚本。因为代码已经存在，所以在初始迁移脚本中实际上有正确的命令来创建这些表，所以我只是将 CreateTable 和等效的 drop 命令剪切到 Up 和 Down 方法中。

现在，再次运行Update-Database并观察它执行新的迁移脚本，在数据库中创建适当的表。

第七步：再次确认并提交。 构建、测试、运行。确保一切都在运行，然后提交更改。

第 8 步：让团队的其他成员知道如何继续。 当下一个人更新时，EF 将不知道是什么击中了它，因为它之前运行的脚本不存在。但是，假设本地数据库可以被删除并重新创建，这一切都很好。他们需要删除本地数据库并再次从 EF 创建它。如果他们有本地更改和待处理的迁移，我建议他们在 master 上再次创建数据库，切换到其功能分支并从头开始重新创建这些迁移脚本。