将数据库移动到新服务器后，无法在 Visual Studio 2010 的实体框架设计器中看到 SQL Server 2008 表

Posted 2023-03-04

【中文标题】将数据库移动到新服务器后，无法在 Visual Studio 2010 的实体框架设计器中看到 SQL Server 2008 表

【英文标题】：Unable to see SQL Server 2008 tables within entity framework designer of visual studio 2010 after moving database to new server

【发布时间】：2012-01-21 10:42:10

【问题描述】：

在尝试更新 Visual Studio 2010 中的实体框架图 (EFD) 时，我在查看某个特定 SQL Server 2008 数据库中的表时遇到问题。这在将数据库移动到新服务器之前一直有效。此服务器上的所有其他数据库都成功显示了它们的表（在 VS 实体框架设计中 > 右键单击​​ > 从数据库更新模型 > '添加' 选项卡 > 展开表 = 此处不显示任何内容）。

STR

我在计算机 A 上创建了一个数据库，并在同一台计算机上使用 Visual Studio 2010 构建网站应用程序。一切正常。

然后我将数据库和网站应用程序文件移动到主服务器计算机 B。

我尝试从计算机 A 的 VS 进行连接，但在尝试更新我的 EFD 时无法看到任何数据库表。

我尝试在计算机 B 上本地打开 VS，但仍然看不到 EFD 表。

我尝试备份/恢复数据库以查看是否是操作系统文件问题。

我尝试创建一个新数据库并使用 SQL Server 中生成的脚本构建新数据库，但没有成功。

我还尝试过更改数据库的所有者，转移到 sql 身份验证并返回到 Windows 身份验证，甚至为我认为不相关的不同用户（例如系统和来宾）添加安全性。

我认为这是一个权限问题，但我似乎无法在有效的数据库中发现任何差异（在实体框架设计器中正确显示它们的表）和这个不存在的数据库。我也看不到用户 VS 可能使用什么来获取表信息，我会假设我已经设置了连接但不确定。

我完全被困住了。在实体框架设计器中，我尝试使用“System.Data.SqlClient”进行连接，Windows 集成身份验证（应该使用系统上的管理员帐户和数据库的所有者）。实体框架的连接字符串如下：

metadata=res://*;provider=System.Data.SqlClient;
    provider connection string="Data Source=localhost;Initial Catalog=myDB;
    Integrated Security=True"

最后一点 - 如果我只是进入服务器资源管理器右上角的 VS，我可以在那里创建一个连接并查看所有表格。但是，不幸的是，这对我的 EFD 没有帮助。

【参考方案1】：

可能是您的实体框架的不同版本，但这些连接字符串中似乎缺少某些内容，我的看起来像这样：

 connectionString="metadata=res://*/xxx.csdl|res://*/xxx.ssdl|res://*/xxx.msl;provider=System.Data.SqlClient;provider connection string="data source=xxx;initial catalog=xxx;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />

在提供者声明之前我有一堆东西。

您是否也尝试过删除 .config 文件中的连接字符串并按照此答案中的说明重新运行向导：How should I edit an Entity Framework connection string?？

最后，您是否尝试过使用有效的连接生成另一个 .edmx 文件？如果您对与您的数据库设计不匹配的对象层进行了很多自定义更改，我想这不是创建的。

【参考方案2】：

问题排查步骤：

新建空白数据库 从旧版本中生成脚本 一一运行脚本，看看是什么破坏了它（每个表、视图等一一）

我发现这很好用，没有任何问题，但不同之处在于我没有创建新架构和用户 NT AUTHORITY/SYSTEM 直到脚本的最后，它们在运行时在开始时被创建以前的完整脚本（并且它不起作用）。我不知道为什么这会是一个问题 - 所有表都是用“dbo”创建的。无论如何前缀，所以不应该放在这个架构中。

考虑到这一点，我进入了我的原始数据库，并简单地删除了 NT AUTHORITY/SYSTEM 的架构和用户登录名，一切正常。同样，如果有人有的话，我会喜欢 cmets。

现在一切正常，我什至重新映射了此用户的安全性以允许再次公开访问数据库，并以相同的名称为其创建了默认架构，并且工作正常。我真的无法解释这一点。