嗨，

最好的解决方案是使用SAP标准工具进行日志记录，例如SLG1。

这是akankshi prasad撰写的有关此主题的博客

https： //blogs.sap.com/2012/04/18/create-and-view-log-using-slg0-and-slg1-transaction /

继续前进，这是愚蠢的做法，因为它已被证明不是一个可以证明未来的解决方案，明智的做法是承认自己的错误并加以解决。

亲切的问候，Rob Dielemans

您必须回答的第一个问题是：您是否想在很长一段时间内甚至是永远保持对这些记录的跟踪（即使没有人在建造） 永远永恒）

• 如果不是：清除最旧的记录，如果是：存档数据（标准应用程序日志作为两个选项，请设置一些到期日期或使用归档对象BC_SBAL）
• 然后从0重新启动范围号，并观察范围号以防止重复键错误。

其他解决方案可以是增加密钥类型的大小，并提供足够大的大小以报告地平线以下的问题（例如，何时技术将发生变化或您的退休计划日期...），并添加年份字段 例如实际上是在键上添加4个字符（还每年管理范围号）

普拉，

顺便说一句，您现在达到的最大限制是什么意思？ 从该表中获取数据时，计数器的字段长度还是记录数一直在增加，从而导致性能问题。

如果表中有日期字段，则决定一个过渡日期并删除该过渡日期之前的记录。

您可以开发一个自定义程序来执行此活动，如果需要，可以将其安排为后台作业。

您甚至可以考虑使用SARA收集数据的选项。

Kiran。

如果您所说的是"错误日志"表，那么为什么需要归档？ 具有法定保留期限的业务信息需要存档（例如，发票可能必须保留N年）。 实用程序/技术表中的数据只需定期删除即可。

对于这样的表，这似乎是一个糟糕的关键选择，但是不幸的是，现在您仍然对此感到困惑。 正如其他人所说，就"创可贴"级别的解决方案而言，您将需要修改更新计数器的代码。 您可以为此使用标准的数字范围功能（SNRO事务）。 这些范围可以自动"滚动"，有一个标记。 在Google上搜索之前，已经在SCN上讨论了此功能。

但是更好的解决方案是重新设计整个设计。 我想知道为什么当我们具有标准的应用程序日志功能时，为什么甚至需要自定义表。 这些天来，它带有这些类，具有自己的显示事务和清理过程。 或者，如果您必须具有Z表，那么至少它需要具有更适合预期数据量和使用情况的键。 您可以使用一些通用数字，例如GUID，这应该可以防止密钥在很长时间内用完。 或者，您可以选择不同的字段组合作为关键字，具体取决于如何访问此数据。 （这部分尚不清楚，因此很难提供更具体的建议。）

无论哪种方式，您都需要一个程序来删除旧条目，并且该程序应在后台作业中定期运行。

如果表大小有问题，可以考虑使用存档或 清除这些数据。 如果应保留数据，请使用存档，并按照存档开发工具包中的说明进行创建， 安排使用SARA进行存档，并修改一些显示程序以允许读取存档。

如果密钥限制/大小有问题，则可以在范围号管理密钥SNRO之前添加时间/日期类型的密钥，例如年份。

您写的内容暗示一些错误记录？

"基于错误日志以及每次创建错误时客户用于递增的msgno。

在这种情况下，为什么不使用sap工具提供的标准日志记录（请参阅：应用程序 登录–（BC-SRV-BAL）），这样就可以免费获得提供的工具吗？

感谢Rob，Kiran，Himanshu和Jelena的评论。

嗨，

如果在同一时间戳上有许多消息，则可以将时间戳值（日期+时间）与增量编号一起使用。

致谢

Himanshu