ASP.Net 会员.删除用户
在测试中，我使用的数据库的用户是一个大jefe。 在生产中，他只有执行。
当我打电话时，
Membership.DeleteUser(user)
在测试中，它起作用了。 我在生产中尝试了同样的方法，我得到了这个：
DELETE 语句与 REFERENCE 约束冲突 “FK__aspnet_Us__UserI__37703C52”。 数据库发生冲突 “测试”，表“dbo.aspnet_UsersInRoles”，列“UserId”。
在我的seagles（Google搜索）中，我发现了这个链接 那家伙说的地方，
错误：DELETE 语句发生冲突 带有 REFERENCE 约束 “FK__aspnet_Me__UserI__15502E78”。 这 数据库发生冲突 “您的数据库名称”，表 “dbo.aspnet_Membership”，列 “用户 ID”。
我花了一段时间才找到解决方案 跨多个站点和选项 作为错误和可能的解决方案 相当具有误导性。 事实证明，在 至少就我而言，这是一个问题 具有会员权限 数据库。 我正在使用的用户 连接有权查看 数据库中的会员详细信息 本身，但作为 aspnet_Users_DeleteUser 已存储 它从以下过程中选择 系统对象表。 会员资格 连接用户显然没有 有足够的权利这样做 select所以整体删除失败。
对我来说，解决方法是将用户添加到 aspnet_Membership_FullAccess 角色 用于会员数据库。
但当我这样做时，它不起作用。 有人对如何处理这个问题有任何想法吗？
In testing, the user on a db i've used was a big jefe. In production, he only has Execute.
When I called,
Membership.DeleteUser(user)
In testing, it worked.
I try the same in production, and I get this:
The DELETE statement conflicted with the REFERENCE constraint
"FK__aspnet_Us__UserI__37703C52". The conflict occurred in database
"Testing", table "dbo.aspnet_UsersInRoles", column 'UserId'.
In my seargles (searches on Google), I came across this link
where the dude was saying,
Error: The DELETE statement conflicted
with the REFERENCE constraint
"FK__aspnet_Me__UserI__15502E78". The
conflict occurred in database
"YourDBName", table
"dbo.aspnet_Membership", column
'UserId'.Took me a while to find a solution to
this across multiple sites and options
as the error and possible solutions
were rather misleading. Turns out, at
least in my case, it was a problem
with permissions on the membership
database. The user I'm using to
connect had access to view the
membership details within the database
itself, but as part of the
aspnet_Users_DeleteUser stored
procedure it selects from the
sysobjects table. The membership
connection user apparently did not
have sufficient rights to do that
select so the overall delete failed.The fix for me was to add the user to
the aspnet_Membership_FullAccess role
for the membership database.
But when I did that it didn't work. Anyone have any ideas on how to deal with this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
经过一番检查后，我发现问题是 aspnet_Users_DeleteUser 存储过程中的这一行：
对于其他 3 个表，还有 3 个类似的行。 问题是，如果执行存储过程的用户无权访问 vw_aspnet_MembershipUsers，则在从 sysobjects 中进行选择时它不会出现。 我很好奇为什么整个 EXISTS 声明是必要的。
无论如何，以下讨论“无需访问权限即可访问sysobjects查看用户表直接在 SQL Server Security 中访问用户表”，有答案。 通过在相关视图上授予“VIEW DEFINITION”，EXISTS 语句现在将成功，并且您不必在应用程序的连接字符串中向用户授予不需要的、不需要的或过多的权限。
After a little inspection I found the issue is this line in the aspnet_Users_DeleteUser stored procedure:
There are 3 other similar lines for 3 other tables. The issue is that if the user executing the stored proc doesn't have access to vw_aspnet_MembershipUsers it won't turn up when selecting from sysobjects. I'm curious to know why that whole EXISTS statement is necessary.
Regardless, the following discussion, "Access to sysobjects to view user tables without having access to the user tables directly in SQL Server Security", has the answer. By granting "VIEW DEFINITION" on the views in question, the EXISTS statements will now succeed and you don't have to grant unneeded, unwanted, or excessive permissions to the user in your application's connection string.
我也遇到了这个问题，它是由缺少视图引起的，为了纠正我只是使用另一个数据库的创建脚本并重新创建了所有 vw_aspnet_* 视图。
I also had this issue and it was caused by missing views, to correct I just used the create script from another database and recreated all the vw_aspnet_* views.
好吧，你猜怎么着？ 我读到了这个：
http://forums.asp.net/t/1254087.aspx
并授予生产用户 SELECT 权限，瞧！
有用！
多谢你们！
OK, guess what? I read this:
http://forums.asp.net/t/1254087.aspx
and gave the production user SELECT permission and voila!
It works!
Thanks guys!
我相信您的“REFERENCE”约束实际上是数据库中存在于 aspnet_Users 表和 aspnet_UsersInRoles 表之间的外键。 我认为您正在尝试的用户在两个表中都有其 UserId，并且在您可以从 Users 表中删除它之前，也必须从 UsersInRoles 表中删除它。
您是否尝试过 http://msdn.microsoft .com/en-us/library/system.web.security.roleprovider.removeusersfromroles.aspx 以确保删除该用户的所有角色？ 您也可以通过检查数据库中这两个表的行来进行验证。
I believe your 'REFERENCE' constraint is actually a Foreign key in the database that exists between the aspnet_Users table and the aspnet_UsersInRoles table. I would figure that the user you are trying, has it's UserId in both tables, and before you can remove it from the Users table, it has to be removed from the UsersInRoles table also.
Have you tried http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.removeusersfromroles.aspx to ensure that all the roles are removed from this user? You could verify too by inspecting the rows of these two tables in the database.
如果在 vw_aspnet_MembershipUsers 上授予 ASP 用户 SELECT 权限后错误（或类似的错误）仍然存在，您可能需要为其他一些 vw_aspnet_???? 授予 SELECT 权限 意见也。 特别是“个人资料”和“UsersInRoles”。 否则，由于某些原因，DeleteUser SP 在从这些视图中进行选择时会得到空结果，并拒绝首先从中删除现有条目。
If the error (or similar) still persists after granting the ASP user SELECT on the vw_aspnet_MembershipUsers, you may want to grant SELECT for some of the other vw_aspnet_???? views too. Especially "profile" and "UsersInRoles". Otherwise - for some reasons, the DeleteUser SP gets an empty result when SELECTING from those views and refuses to delete existing entries from them first.
也许更好的是确保执行删除成员资格的用户具有正确的 ASP.NET 成员资格 sql 角色。
就我而言，我正在删除具有某些角色和配置文件属性的会员用户。 删除方法失败，但在分配正确的 sql 角色后，它起作用了。
如果您正在使用该功能，您还可以添加 [aspnet_Personalization_FullAccess]。
Maybe better to make sure the user that executes the delete membership has the to correct ASP.NET Membership sql roles.
In my case I was deleting a membershipuser that has some roles and profile properties. The delete method failed, but after assigning the correct sql roles it worked.
You could also add [aspnet_Personalization_FullAccess] if you are using that functionality.
我通过删除过程中检查视图的行解决了这个问题。 我没有任何 asp 成员资格视图，并且在任何地方都不需要它们，因此创建视图似乎毫无意义，以便该行代码可以返回 true - 过程实际上并不使用该视图。 也许如果您使用成员资格对象的更多功能，您可能需要该视图来实现其他目的。 无论哪种方式检查视图的存在似乎都是一种奇怪的方式，让进程决定 aspnet_membership 表是否有需要删除的行。
I solved this by removing the line in the proc which checks for the view. I don't have the any asp membership views and haven't needed them anywhere, so it seems pretty pointless to create the view just so that line of code can return true - the proc doesn't actually use the view. Perhaps if you use more features of the membership objects you might need the view for something else. Either way checking for the view's existence seems an odd way for the proc to decide whether the aspnet_membership table has a row it needs to delete.