发布站点遇权限错误：Code First迁移无法插入记录并报错

哥们，我之前也踩过类似的Code First迁移权限坑，结合你描述的情况，那个截断的错误提示（Cannot find the objects "Per...”）大概率是因为MY_USER的权限给得不全——EF的Code First迁移可不只是操作__MigrationHistory这一张表，下面给你一步步排查解决：

1. 先拿到完整的错误信息 #

那个错误提示明显被截断了，先把应用程序的完整日志拉出来，看看到底是找不到哪个对象（大概率是某个业务表、系统视图，或者权限相关的系统对象），完整的错误信息能直接帮你定位核心问题。

2. 检查MY_USER需要的核心权限 #

Code First迁移过程中，除了__MigrationHistory的增删改查，还需要这些关键权限：

• 如果迁移涉及表结构变更/新建表：需要对数据库有CREATE TABLE、ALTER权限，对已存在的业务表有ALTER权限
• EF需要读取数据库元数据来对比模型和现有结构：所以需要对系统视图（比如sys.tables、sys.columns、sys.indexes）有SELECT权限
• 对所有业务表的常规CRUD权限（INSERT/UPDATE/DELETE/SELECT）

你可以先给用户授予基础角色来快速验证：

-- 先给数据读写权限，测试是否能正常迁移
EXEC sp_addrolemember 'db_datareader', 'MY_USER';
EXEC sp_addrolemember 'db_datawriter', 'MY_USER';
-- 如果涉及表结构变更，再加上DDL权限
GRANT ALTER ON DATABASE::[你的数据库名] TO MY_USER;
GRANT CREATE TABLE ON DATABASE::[你的数据库名] TO MY_USER;

如果这样能正常执行迁移，再逐步细化权限，避免过度授权。

3. 确认实际执行迁移的用户 #

有时候发布后，应用程序连接数据库用的不是你配置的MY_USER——比如用了应用池的身份账户，或者配置文件里的连接字符串写错了。你可以在数据库里查当前连接的用户：

SELECT login_name, program_name FROM sys.dm_exec_sessions WHERE is_user_process = 1;

看看是不是MY_USER在执行迁移操作。

4. 手动执行迁移脚本排查 #

把Code First生成的迁移脚本导出来（在Package Manager Console里用Update-Database -Script命令），然后用MY_USER的身份在SSMS里执行这个脚本，看具体哪一行报错——这样能精准定位是哪个操作缺权限。

5. 验证__MigrationHistory的权限是否生效 #

有时候权限授予后可能因为上下文问题没生效，你可以用下面的语句检查MY_USER对该表的权限：

SELECT dp.permission_name, o.name AS table_name
FROM sys.database_permissions dp
JOIN sys.database_principals dpri ON dp.grantee_principal_id = dpri.principal_id
JOIN sys.objects o ON dp.major_id = o.object_id
WHERE dpri.name = 'MY_USER' AND o.name = '__MigrationHistory';

确认INSERT、SELECT、DELETE、UPDATE这四个权限都存在。

内容的提问来源于stack exchange，提问作者Adrian