最近，我遇到了一个问题，我的视图索引一直在重建，用户在这个特定视图中遇到了大量问题。
我认为这是由于我的选择公式中的@Date以及我的一个列公式。这样，选择公式每过一步就会不同。
所以我想，由于我的公式中不需要小时/分钟/秒，我会使用@Today。这样做了2-3天，之后又出现了同样的问题。
因此问题又回来了，我不太确定这是否会导致问题。当这个特定视图打开时，我在注释中打开的每个选项卡中都会出现问题，而不仅仅是这个特定的数据库。
这是一个常见/已知的问题吗？我该怎么做才能避免这个问题？
答案 0 :(得分：3)
是的，这是自20多年前Notes早期以来众所周知的常见问题。
@Date本身不是问题。 @Now和@Today都是问题。
使用@TextToTime（“今天”）是早期发现的一种流行的解决方法。这隐藏了索引器的问题，因此服务器未能意识到视图已过期。然而，它并没有解决潜在的问题，即视图试图做一些视图根本不是设计用来做的事情。视图是静态的，只有在文档发生变化时才需要更新。将时间引入选择或列公式会使它们变得动态，从而杀死这种假设，并且是性能问题的主要来源。使用此变通方法要求每晚完全重建视图。您可以通过设置view index options to "Manual"并设置program document为特定数据库运行updall command with the -T option并每晚查看一次来实现。请注意，如果您的用户分布在时区，您必须选择一个特定的时间作为标准，如果您的服务器分布在时区，您将有很多乐趣找出如何使它们全部在视图中始终显示相同的文档 - 但这几乎是解决问题的所有方法。
请参阅此IBM Technote，了解人们多年来使用过的其他几个选项，以及它们的优缺点。另请参阅此article by Andre Guirard，其中详细介绍了日期/时间问题。
我想补充一点，他们在Technote中描述的代理和文件夹解决方案通常是我首选的方法，但它确实有一个额外的缺点，他们没有提到：它最终会导致一个模糊的情况，其中服务器抛出错误“文件夹大于支持”。此错误实际上与文档中文件夹的大小无关;它指的是随着时间的推移大量文档移入和移出文件夹时发生的内部结构碎片。只能通过删除和重新创建文件夹来修复，您可以在代理程序代码中执行此操作。我相信这个问题可能会在更新版本的Domino中修复，但它在Notes 6和7时间框架中引起了很多悲痛。