您好，

您可以看到消息本身中的错误，指出DSO未锁定。 尝试检查SM12中为什么有锁？ RSICONT是一个表，用于存储有关已实际加载到目标中的所有请求的信息。 您可能无法锁定信息提供者0PROD_CATEG。 还要确认信息提供者是否正在进行任何加载。 如果是，则等待它克服。 然后重试。

请检查SM12中为什么存在该锁，并确认是否可以删除该锁。 如果不是，则等待锁释放，然后重试。 该工作应该成功。

谢谢

嗨，

请在下面看看，

如果" 管理InfoCube需要花费很长时间，当您管理信息提供者时，管理部门不仅会显示所有请求，还会检查所有请求。 在执行此操作时，必须在请求列表上进行任何更改。

为确保这一点，DataTarget仅在短时间内被锁定。

正常的数据加载过程会锁定数据目标 两次：在新的加载过程开始时，一次将请求放入数据目标的请求列表中，然后在最后一次使请求变为红色或绿色。

如果您已经有很多请求 在数据目标中，则此锁定可能需要几分钟。

在此期间，由于此列表是由同一函数收集的，因此没有其他人可以更改此InfoCube的请求，甚至无法显示请求列表。

但是请求的显示不会 等待锁定无休止，但只有几秒钟。 之后，它异常终止，显示一个空的tablecontrol，并且

错误消息" RSM854由于无法锁定InfoCube而刷新显示中止"

显示在屏幕底部的消息行中。

这可能是有时不显示任何请求的原因。

希望这会有所帮助。

问候，

Mani

嘿pawan和玛尼...

一吨的答复...

guyz，

我已删除了该锁的条目并再次加载。

成功了。

cheerz，

说唱。

您好，
您应遵循以下解决方案；

要确定请求是在锁定DSO/InfoCube，请检查表 RSBKREQUEST。

您需要将DSO/InfoCube检查为DTP的源和目标。

1. T代码SE16->输入表RSBKREQUEST。
2. 将DSO/CUBE ID输入到字段SRC（DTP的源对象名称）
3. 查找具有USTATE = 5的请求
4. 将DSO/CUBE ID输入到字段TGT（数据传输过程的目标对象）
5. 查找具有USTATE = 5的请求

如果没有这样的请求（USTATE = 5），则此KBA与您的问题无关。

如果找到了请求，请等待直到请求完成为止，或者通过单击将其在T-Code RSRQ中手动更改为"红色"或"绿色"。

BR，
Furkan