等待最多xx秒是一个糟糕的主意，我不明白为什么开发人员会使用它。

好的，您会发现2秒钟适合您的情况，这很好，测试还可以。 和?? 您将转到Integration/Quality系统，秒数应为2.34 ...，以便您对其进行纠正...，在生产中，它有时为1.234秒，有时为4.567，并且程序有时会运行

根据您所说的，您的伪代码为：

 1。 当条件。
 2.调用功能'BAL_DB_SEARCH'...
 3.提交工作并等待。
 4.通话功能'BAL_DB_DELETE'...
 5.等待最多1秒。
 6.最后。

真的，您没有看到问题吗？

更新：要明确地说，删除后必须完成提交工作（并等待），然后等待 最多1秒是无用的（根据您的信息）。

您说您的代码应删除日志（我同意，BAL_DB_DELETE删除日志），并且某些日志没有删除。 我知道两种可能性：要么某些日志已经被锁定，要么存在一个BAL_DBDEL_ 功能模块，该功能模块可防止删除日志。 那么它可能是一个异步删除的锁。 在" DO"循环之前添加最多10秒的等待时间，以确保是原因，然后告诉我们上下文，以便我们可以为您提供帮助（我只能说您将自定义代码放置在错误的位置） 。

尽管我同意 Sandra Rossi 的观点，但您可能会同意 要首先检查您的初始代码，您是否尝试过使用BAL_DB_DELETE的导入参数？ 您可能还想检出一个I_IN_UPDATE_TASK参数。 以及为什么在通过参数I_WITH_COMMIT_WORK在BAL_DB_DELETE中再次执行显式提交工作时呢？ 因为您的计划在调试模式下有效，所以有点儿告诉我您将SAP LUW组合在一起的原因是，您的显式提交工作与长达1秒的等待时间结合在一起（尽管我不是SAP LUW的专家）。 因此，如果您摆脱了显式提交，而让SAP处理数据库提交本身呢？

好的，谢谢。

在搜索要删除的日志之前，必须确保所有日志都已提交到数据库。

因此，在执行SLG1日志搜索和删除过程之前，我需要在同一ABAP程序中调用FM DB_COMMIT（如下代码）。

然后，我对日志做了一次LO LOOP TO SEARCH（搜索到日志），如果发现要删除它们，那么在删除后我将执行此循环2次，并提交一次。

但是，运行上述标准过程后，红色日志仍然存在。 同样，在调试时，它可以正常工作。

在SLG1搜索过程之后使用无限循环调试代码时，我发现（在调试中）搜索过程检索到了我要删除的所有日志。

因此，在它甚至不知道即将进入调试状态之前，我正在用我要删除的所有日志填充itab。 然后，我使用此Itab中的所有内容调用日志删除过程。

就像搜索过程从数据库（即SLG1表）以及其他地方（缓冲区??）读取记录一样。

说实话，我现在被骗了。 有什么想法吗？

谢谢

标记

请使用COMMENT按钮进行评论，提问，添加详细信息等。ANSWER仅是提出解决方案，请在答案区域的右侧删除SAP文本： 回答之前您仅应在提出解决海报问题的方案时提交答案。