我们的 ERP 系统是一个混合体。实际数据是 SQL，但包含用户信息、配置文件、权限、安全性等的表在 Visual FoxPro 中。
我需要获得对 VFP 数据库的独占访问权限。我使用程序本身将所有人从系统中删除，这表明所有人都在系统之外。我收到以下代码的以下响应：
set excl on
open data l:\M2MDATA\Util\util.dbc excl
我得到的响应是：文件访问被拒绝。我进入服务器管理器，没有人在我们的 VFP 目录中打开任何文件。
VFP 中是否有一个命令可以让我确定谁/什么打开了文件和/或杀死 FoxPro 中的任何会话的方法？
我尝试用谷歌搜索它，但没有运气。
【问题讨论】：
标签： foxpro visual-foxpro
您可能想查看 Sysinternals (Microsoft) 的 Process Explorer。
http://technet.microsoft.com/en-us/sysinternals/default.aspx
您可以使用查找 |文件句柄或 DLL 菜单选项并输入 DBC 文件的名称。 Process Explorer 会告诉您进程 ID 和打开文件的进程。
如果您在网络上共享文件（文件服务器或点对点），请转到“服务器”并运行计算机管理。深入到共享文件夹 > 打开文件，您应该会看到网络上其他用户在计算机上打开的文件列表。
瑞克
【讨论】：
正如 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
【讨论】：
可能是某个程序在打开数据库（留下僵尸锁）或通过未释放资源的网络共享连接数据库时崩溃。
在这种情况下，我通常只能重新启动数据库所在的服务器，或者卸载/重新安装数据库所在的磁盘（如果在 SAN 或网络磁盘上）。
【讨论】：
在 Microsoft 的支持站点上查看服务器 Opportunistic Locking 和 Cached Open 设置。如文章所述，您可能需要将 EnableOplocks 设置为 0 并将 CachedOpenLimit 设置为 0。访问病毒扫描也因这类事情而臭名昭著。
除了提到的出色的 SysInternals Process Explorer 工具外，我还使用了一个名为 UnLocker 的工具，它可以让您右键单击服务器上的任何文件并查看锁定进程。
还有另一个名为“handle”的 SysInternals 工具，它在提示符下运行并提供大量信息，说明哪些进程在给定文件上拥有句柄。
【讨论】：
你可以试试这个：
重新启动服务器（如果可能）。现在没人用了。
获取链接到 DBC 的表的列表并编写脚本以单独且独占地打开每个表。是否有任何打开失败？
可能其中一个表被反向链接到另一台服务器上的表。
只是一些想法。
【讨论】：
可能值得确保您可以打开它以进行共享访问，以确保这不是权限问题。
【讨论】：
我之前收到过该消息，问题很简单，运行 Windows 资源管理器并尝试打开文件所在的文件夹。如果您无法访问该文件夹，visual foxpro 也是如此。我假设您正在使用共享文件夹，因为您提到您正在使用驱动器 L. cmiiw :)
【讨论】：
我遇到了同样的问题（没有对 DBC 的独占访问），但还有另一个原因。
我们正在通过低级命令（FOPEN、FSEEK、FPUTS、FCLOSE、FCREATE）处理文本文件中的访问和某些活动的协议。我们从 2000 年 4 月 1 日开始这样做，没有任何问题。
在发生“严重不良网络事件”后，我们的系统仍然运行，但速度极快。协议中的每个动作大约需要 5 分钟。 FoxPro 显然在 5 分钟内重试了低级程序，最后跳过了它们（顺便说一句，没有任何通知）。
文本文件绝不是数据库本身的一部分。尽管如此，DBC 无法通过来自机器（关机）的僵尸锁访问，该机器也是文本文件的僵尸锁的所有者。 DBC 锁只能在 txt 文件的锁帽被移除后才能被释放。
不知道，这是如何连接的，但之后，一切又好了，现在仍然如此。服务器是 Novell Netware，我不熟悉。
【讨论】：