2

我们的 ERP 系统是混合的。实际数据是 SQL，但包含用户信息、配置文件、权限、安全性等的表在 Visual FoxPro 中。

我需要获得对 VFP 数据库的独占访问权限。我使用程序本身将所有人从系统中删除，这表明所有人都在系统之外。我得到以下代码的以下响应：

set excl on
open data l:\M2MDATA\Util\util.dbc excl

我得到的响应是：文件访问被拒绝。我进入服务器管理器，没有人在我们的 VFP 目录中打开任何文件。

VFP 中是否有一个命令可以让我确定谁/什么打开了文件和/或杀死 FoxPro 中的任何会话的方法？

我试着用谷歌搜索它，但没有运气。

4

8 回答 8

6

您可能想查看 Sysinternals (Microsoft) 的 Process Explorer。

http://technet.microsoft.com/en-us/sysinternals/default.aspx

您可以使用查找 | 文件句柄或 DLL 菜单选项并输入 DBC 文件的名称。Process Explorer 将告诉您进程 ID 和打开文件的进程。

如果您在网络上共享文件（文件服务器或点对点），请转到“服务器”并运行计算机管理。深入共享文件夹 > 打开文件，您应该会看到网络上其他用户在计算机上打开的文件列表。

瑞克

于 2009-08-28T02:32:31.613 回答
4

正如 Jeff 所提到的，一件事可能是当一个人的机器崩溃时，他们会从网络断开连接。服务器仍然认为文件在某个低级句柄处打开。然后，当用户重新连接时，所有先前的设置似乎都会自动释放，重新进入系统，然后一切似乎都很好。此外，检查计算机管理下的从服务器、共享驱动器以及谁可能实际打开了文件，即使他们可能有不正常的断开连接。

作为在表上预先测试这种排他性的替代方法，您可能想尝试对 .DBC 运行查询，因为它也只不过是一个表本身......就像

nStatus = 0
try
   use L:\M2MData\Util\Util.dbc shared
   ** Ok so far, now try exclusive
   nStatus = 1
   use L:\M2MData\Util\Util.dbc EXCLUSIVE
   nStatus = 2

catch to loTrapMsg
   messagebox( "Can't get exclusive use of DBC" )

endtry 

if nStatus = 2
   ** you have exclusive use of it as a simple TABLE
   ** Now, what do you want to do
   use
   open database L:\M2MData\Util\Util.dbc EXCLUSIVE

endif
于 2009-08-27T00:32:18.253 回答
2

某些程序可能在数据库打开（留下僵尸锁）或数据库通过未释放资源的网络共享连接时崩溃。

在这种情况下，我通常只能重新启动数据库所在的服务器，或者卸载/重新安装数据库所在的磁盘（如果在 SAN 或网络磁盘上）。

于 2009-08-26T19:58:50.450 回答
2

在 Microsoft 的支持站点上查找服务器 Opportunistic Locking 和 Cached Open 设置。如文章所述，您可能需要将 EnableOplocks 设置为 0 并将 CachedOpenLimit 设置为 0。访问病毒扫描也因这类事情而臭名昭著。

除了提到的出色的 SysInternals Process Explorer 工具外，我还使用了一个名为 UnLocker 的工具，它可以让您右键单击服务器上的任何文件并查看锁定进程。

还有另一个名为“handle”的 SysInternals 工具，它在提示符下运行，并提供有关哪些进程在给定文件上具有句柄的大量信息。

于 2009-09-02T09:41:12.953 回答
2

你可以试试这个：

  1. 重新启动服务器（如果可能）。现在没有人使用它。

  2. 获取链接到 DBC 的表列表并编写脚本以单独且独占地打开每个表。是否有任何打开失败？

  3. 可能，其中一个表被反向链接到另一台服务器上的表。

只是一些想法。

于 2009-09-28T02:59:12.693 回答
1

我之前收到过这条消息，问题很简单，运行 Windows 资源管理器并尝试打开文件所在的文件夹。如果您无法访问该文件夹，visual foxpro 也是如此。我假设您正在使用共享文件夹，因为您提到您正在使用驱动器 L. cmiiw :)

于 2009-10-19T12:16:39.037 回答
1

可能值得确保您可以打开它以进行共享访问，以确保它不是权限问题。

于 2011-10-11T21:33:04.213 回答
1

我有同样的问题（没有对 DBC 的独占访问），但还有另一个原因。

我们正在通过低级命令（FOPEN、FSEEK、FPUTS、FCLOSE、FCREATE）处理文本文件中的访问和某些活动的协议。我们从 2000 年 4 月 1 日开始这样做，没有任何问题。

在“严重的不良网络事件”之后，我们的系统仍然运行，但速度非常快。协议中的每个动作大约需要 5 分钟。FoxPro 显然在 5 分钟内重试了低级程序，最后跳过了它们（没有任何通知，顺便说一句）。

文本文件绝不是数据库本身的一部分。尽管如此，DBC 无法通过来自机器（关机）的僵尸锁访问，该机器也是文本文件的僵尸锁的所有者。DBC 锁只能在 txt 文件的锁帽被移除后才能被释放。

不知道，这是如何连接的，但之后，一切都很好，现在仍然如此。服务器是 Novell Netware，我不熟悉。

于 2010-05-18T09:52:58.653 回答