您可以尝试使用

MXREF_MX_PRIVILEGE = {BYPASS_VALIDATE_TASK = 1 !! BYPASS_MEMBER_TASK = 1 !! BYPASS_MODIFY_TASK = 1} [D} PRIV：....：...

看看是否有所作为。 如果不是，您需要向我们提供作业的更多详细信息。 例如mcOrphan，mcDirectAssign，mcLastAudit和其他我不记得了的列：-)

顺便说一句：ChangeType = DELETE将删除MSKEYVALUE给定的条目，因此请务必小心。 您可能应该检查该条目本身是否在MXI_ENTRY.mcState列中未标记为"待删除"（认为"待删除"的值为3），这可能会阻止对该条目进行其他操作。

迈克尔，你好，

您正在运行哪个IDM版本？ 您是否尝试过uIS_PrivReconcile函数？

干杯

沉阳

嗨迈克尔，

在IDM UI中使用删除操作可能不起作用的原因可能有多种。

大多数原因是分配损坏-启用了禁用标志的活动链接。

（检查选择mcthismskey，mcothermskey，mcexecstate，mcdisabled from mxi_link，其中mcthismskey = user-mskey和mcothermskey = priv-mskey//活动链接不应具有禁用标志（mcdisabled = 1））

这只是一个例子，原因可能在数十个之内。

要删除您的特权，您可以首先尝试修复已经分配的链接，以便供应框架可以在UI中捕获您的取消供应操作，或者您可以尝试直接从数据库中删除它：

从mxi_link中删除mcuniqueid所在的地方（

从mxi_link中选择mcuniqueid，其中mcthismskey = user-mskey，而mcothermskey = priv-mskey），然后手动将其从后端删除，这不太可能被推荐，但可以。

Lukasz

谢谢，

我们尝试了SAP提供的维修解决方案，但仍无济于事，这开始影响越来越多的用户。

当前有一张SAP支持票证已经开放进行了4周，而我们在此问题上获得的支持很少。 此过程在sp7之前就已完美运行，但是一旦移至8，我们的业务角色更新都将无法工作，并且用户现在处于这种混乱状态。

嗨，迈克尔，

让我为您提供解决孤立条目问题的合适解决方案，当我们通过将业务角色设置为业务角色（例如，将MX_ROLE设置为MX_ROLE）或将业务角色设置为特权（例如将MX_ROLE设置为MX_PRIVILEGE）时，将创建孤立条目。 ），当我们为用户分配业务角色时，将在属性MXREF_MX_ROLE中设置角色，并为属性MX_AUTOPRIVILEGE设置业务角色中的特权。

如果要删除特权，可以使用属性MX_AUTOPRIVILEGE而不是MXREF_MX_PRIVILEGE来删除孤立项。

此致

Kishor