在将数据库从SQL2016恢复到SQL2019之后，当我试图访问数据库图时遇到了同样的问题。我已经有正确的数据库所有者，但文件的所有者是空的。一旦我设置好了，它就正常工作了……

选择的答案和其他一些都很好。我只是想给出一个更纯粹的SQL解释。同样的解决方案是没有(有效的)数据库所有者。

错误中提到的数据库所有者帐户dbo总是用数据库创建的。所以看起来很奇怪，它不存在，但你可以检查两个选择(或一个，但让我们保持简单)。

SELECT [name],[sid] 
FROM [DB_NAME].[sys].[database_principals]
WHERE [name] = 'dbo'

显示DB_NAME数据库中dbo用户的SID和

SELECT [name],[sid] 
FROM [sys].[syslogins]

以显示此SQL服务器实例的所有登录名(及其sid)。注意，它没有写任何db_name前缀，这是因为每个数据库在该视图中都有相同的信息。

因此，如果出现上述错误，将无法使用分配给数据库dbo用户的SID登录。

如上所述，这通常发生在从另一台计算机恢复数据库时(其中数据库和dbo用户是通过不同的登录创建的)。您可以通过更改现有登录名的所有权来修复它。

做图形。

数据库右键点击——>属性——>文件——>选择数据库所有者——>选择[sa]——ok

进入属性-文件。 所有者名称必须为空。只要在用户名中输入“sa”，问题就会得到解决。

在我的情况下，我得到这个错误时，试图冒充另一个用户。如。

EXEC AS USER = 'dbo';

由于数据库是从另一个环境导入的，因此它的一些用户与SQL Server登录名不匹配。

您可以通过运行(已弃用的)sp_change_users_login(在“报告”模式下)来检查是否有相同的问题，或使用以下查询:

select p.name,p.sid "sid in DB", (select serp.sid from sys.server_principals serp where serp.name = p.name) "sid in server"
from sys.database_principals p
where p.type in ('G','S','U')
and p.authentication_type = 1
and p.sid not in (select sid from sys.server_principals)

如果在该列表中显示了您试图模拟的用户，那么您可能可以通过将DB用户分配给服务器中的正确登录来修复它。例如:

ALTER USER dbo WITH LOGIN = dbo;

当意外地将数据库连接字符串提供给只读镜像时也有此错误-而不是HA设置中的主数据库。