我们在 Notes 数据库中遇到了一个罕见的生产问题。我们的系统会在提交过程中为请求文档分配一个 ID（保存然后实时提交）。发生的情况是，有时 2 个文档似乎具有相同的 ID，但事实并非如此。
ID 的格式为 YYYY-MM-XXX，其中 YYYY 是当前年份，MM 是月份数字，XXX 是从 001 开始的数字。系统在分配 id 时，会在视图中检查相同月份的文档所在的位置。如果它没有看到文档，则在 ID 中分配 001，否则，它将获取视图中的最新文档，获取数字，然后将其递增 1。然后，新号码将被分配为 ID。
如何确保在此过程中，我可以根据上述条件分配唯一 ID？该错误非常罕见，我们无法再次模拟它。感谢您的帮助！
您可以使用 NotesDocument 对象的 lock 方法先锁定文档，然后再更新文档中的数字。如果另一个用户进来，脚本需要等到锁被释放。释放锁后，下一个用户可以锁定它以更新它。
一些代码将有助于查看问题所在，但听起来两个提交文档的用户之间存在争用条件，他们同时查看视图。
在查看视图、获取最新文档、将其递增 1、将其存储在文档上、保存该文档，然后更新视图以便下次检查视图时，最新文档具有更大的数字的逻辑过程中会花费大量时间。 你真正需要的是包装这一切的东西，所以它只能同步发生。 说起来容易做起来难。
我建议使用 @UNIQUE 公式，该公式（我相信）保证是唯一的，而不是 ID 的 XXX 部分。 如果您使用 XXX 部分进行排序，也许您仍然可以将该序列号保存在文档中的某个位置，在最坏的情况下，您将有两个具有相同排序键的文档，这可能适合您的需求。
根据@Ken Pespisa的回答，@Unique更有可能给你一个独特的价值，但它并不能真正保证。如果具有相似名称（即，相同的名字首字母、相同的姓氏前两个字母和相同的姓氏最后一个字母）在两个不同的客户端计算机上完全相同的时间（根据系统时钟）执行@Unique，则仍可能发生冲突。 概率很低，但不是零。
关于将 unqiue 顺序 ID 分配给 Notes 文档的明确讨论可以在 Andre Guirard 的文章中找到。 在我看来，最好的技术是推迟分配唯一的顺序 id，并保留在服务器上运行的代理来创建 id。 这提供了真正的 uniqeuness 保证（只要您正确编码）。代价是 id 不能立即可用。