拥有已使用 13 年的 Lotus Domino 数据库。
今天,一个名为 NumApprovers 的隐藏可编辑字段已开始在多个文档中出现乱码值。
该字段由 lotusscript 更新,它计算多值字段中有多少个名称。
lotusscript 多年来没有改变 - 所以不知道为什么这个字段突然变得奇数。
有任何想法吗?
拥有已使用 13 年的 Lotus Domino 数据库。
今天,一个名为 NumApprovers 的隐藏可编辑字段已开始在多个文档中出现乱码值。
该字段由 lotusscript 更新,它计算多值字段中有多少个名称。
lotusscript 多年来没有改变 - 所以不知道为什么这个字段突然变得奇数。
有任何想法吗?
遗憾的是,我看不到您发布的图像,因此难以诊断。
需要考虑的一些事情... Lotus Notes 可能会让您在多年后因查找时出现 64k 错误而感到悲痛。如果您从@dblookup 或@dbcolumn 的视图中查找项目列表,那么一旦您达到此限制,它将在不通知的情况下翻倒。在 32k 或 64k 上还有一些其他数据限制,这就是我怀疑你遇到的问题。复制并删除一些较旧的数据,看看是否可以解决副本中的问题。
第二件事是数据库损坏。数据库有时会损坏。我会复制数据库并运行“加载修复” - 请参阅您的管理员帮助或http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/Links/H_RUNNING_FIXUP_USING_THE_SERVER_STATUS_TAB_7476_STEPS
最后,它取决于办公桌检查时间。获取数据库的副本并通过 out 添加调试消息,例如
Print "Info: View returned " + cstr(view.entries) + entries"
继续深入研究该过程,直到找到发生损坏的原因。
高温高压
要考虑的另一件事是,您可以让您的用户在更新时签署文档,这可以帮助您至少识别哪些机器/用户导致了损坏。我不相信您的用户会随机开始这样做(尤其是在 13 年后),所以我认为这更有可能是使用 EOL 后硬件的问题,这会导致写入时出现位错误。
但是,无论哪种方式,答案都可能是“导致损坏的硬件故障”,而不是基于时间的软件故障。