Question

我意识到Progress ABL有这样做的自然倾向：

默认情况下，Progress会显示以下消息：正在使用中    上。等待或选择CANCEL停止。（2624）

这条2624消息提供了信息，但通常不是这样   想要，因为用户没有机会提交更改或继续   没有STOP条件。然后他们返回到创业公司   过程

但是，我希望能够在if ______锁定之后显示哪个锁定记录然后执行：显示和特定记录已锁定

我确实在本文底部的文章中找到了有关使用VST _Lock的信息，但Progress文档逐字说明，“注意：请谨慎查询_Lock表;频繁访问会消耗大量系统资源并消极地影响表现。“是否有替代方法或最佳实践？任何帮助将不胜感激。

https://knowledgebase.progress.com/articles/Article/P182366

Answer 1

我很同情为用户提供关于谁持有锁的好消息。但是kbase并不是在开玩笑。以这种方式使用_LOCK是一个非常糟糕的主意。

11.4+使它变得不那么糟糕但在大型生产系统上做起来仍然是一件非常痛苦的事情。

它似乎是＆＃34; ok＆＃34;在具有默认锁定表大小（-L 8192）的小型系统上。在具有大型锁定表的大型活动系统上（1M以北的-L值是常见的）并且使用了大量锁定，您将获得非常非常不同且非常消极的体验。

更好的解决方案可能是查看＆＃34;阻止用户＆＃34;：

for each dictdb._Connect no-lock
    where _Connect-usr <> ?
      and _Connect-wait <> " -- ":  /* there are spaces around the '--' */

  display _Connect.

end.

这会更快，可能会告诉你需要知道的一切。

如果您要扫描_LOCK，无论kbase的警告是什么，至少在您的循环中放置一些逻辑来跟踪它需要多长时间并且如果它太长就会挽救。这样的事情可能是一个好的开始：

etime( yes ).

for each dictdb._Lock where _Lock._Lock-usr <> ? and _Lock._Lock-recid <> ?:

  if etime > 500 then leave.

  /* whatever ... */

end.

Answer 2

我假设您已经熟悉find ... exclusive-lock / share-lock no-wait no-error，因为您无法使用无等待而无法使用锁定功能。

查询_lock可能不会那么糟糕，因为评论会发出声音。您只会在用户遇到锁定冲突时偶尔执行此操作。此外，性能在很大程度上取决于当前锁定的条目总数。

重要的是以正确的方式查询_lock，具体取决于Progress版本。

重复my answer to a similar question：

_LOCK始终具有-L中给出的全部条目数，无论当前存在多少个锁。
在11.4之前的版本中，字段未编入索引，但所有使用的锁都在表的开头，因此您可以使用
```
FOR EACH _Lock NO-LOCK:
  IF _Lock._Lock-Usr = ? THEN LEAVE.
```
（_ Lock._Lock-Name =？也没关系）。请参阅http://knowledgebase.progress.com/articles/Article/P161995（显然，对于非常大的锁定表或许多锁定，这在实践中并非如此。由于扫描整个锁定表确实需要一些时间，因此这可能是您可以做的最好的。）
在11.4和11.5中，填充的条目不再位于开头，因此旧代码将给出错误的结果（请参阅http://knowledgebase.progress.com/articles/Article/000056304，这在11.5.1中已修复）。幸运的是，扫描锁表现在要快得多，所以你可以使用
```
FOR EACH _Lock NO-LOCK WHERE _Lock-Recid <> ?:
```
在同一篇文章中提到。从技术上讲，这不是通过索引实现的。（索引不能与＆lt;＆gt;运算符一起使用。）
从11.5开始，两个变种都应该有效，但是带有where-phrase的新变种应该更快。

Progress ABL，如何确定哪个最终用户锁定记录并显示给锁定记录的其他最终用户？

2 个答案: