我正在编写一个小软件，它将成为使用 dbf foxpro 表的现有应用程序的一部分。我的应用程序只读取 2 个表填充一个数据集并关闭连接，非常快速和简单。它一直有效，直到其中一个表被使用或由 foxpro 本身（当打开表时）或由主应用程序访问该表时使用。
当它发生时得到异常
ex = {“无法打开文件 c:\data\myFile.dbf。”} 错误代码 = -2147217865
是否可以指定我想访问它只是为了阅读而不是编辑？
PS：我正在使用 VS 2008 C# 来访问它。我的连接字符串如下所示：“Provider=VFPOLEDB.1;Data Source=C:\data\”
非常感谢
当您提到“FoxPro 本身”时，我假设您的意思是有人正在运行用于 DOS 或 Windows 的 FoxPro 2.6 或 Visual FoxPro（任何版本）。如果是这种情况，请确保用户在命令行窗口中使用以下命令
SET EXCLUSIVE OFF
或者他们可以打开每个表并在每个 USE 命令中包含 SHARED 子句。
如果您指的是在 FoxPro 中开发的针对数据运行的应用程序，您的情况会稍微复杂一些，因为该应用程序可能被设计为单用户并且在代码中具有 SET EXCLUSIVE ON。在这种情况下，最好的方法是尝试修改现有的 Config.FP 或 Config.FPW（取决于版本）并添加一行：
EXCLUSIVE = OFF
或者，如果文件不存在，您可以创建该文件。如果这不起作用，您将需要应用程序源代码来更改它，这样它就不会专门打开表。
至于您在 C# 程序中使用 VFP OLE DB 驱动程序，您可以在 EXCLUSIVE = OFF 的文件夹中包含一个 Config.FPW 文件，它将确保您以共享模式打开文件，以防万一您尝试独占采用。这不太可能，因为运行时版本不默认为独占，并且 OLE DB 驱动程序遵循运行时标准。
里克·舒默 VFP MVP
您得到的错误代码是 HRESULT 0x80040E37，因为一些中间步骤不知道 unsigned int32 的存在 - 这是“无法打开该表”的通用 ODBC 错误（通常是由于拼写错误）。毫无疑问，Foxpro 和主应用程序正在使用的库正在做某种“锁定”——即使 ODBC 允许您指定您只想阅读，如果其他进程将其打开以供写入，这仍然应该被拒绝（两个或多个只想读取的进程都可以，但即使只有一个想要写入的进程也必须排除所有其他进程，读取器或写入器）。
如果您在短暂读取时无法暂时将 .DBF 文件与其他用途分离，那么一种方法可能是将其复制到另一个名称（仍然是 .DBF）并尝试打开该副本 - 它是否有效，或者仍然失败并出现相同的错误？在后一种情况下，可能有办法破解文件，因此它的“锁定状态”被清除——只要它没有被使用（因为副本不会被使用，直到你设法打开它！-）。完成所需的阅读后，您可以删除副本。
问题是，这种方法虽然可以工作，但并不完全可靠：foxpro 或您的主应用程序可能正在对数据库进行更改（这就是为什么毕竟，他们正在锁定它 - 为了安全起见，他们可以进行更改），并且在您执行复制的那一刻，更改可能部分但不完全提交到磁盘。你有什么方法可以检查你正在阅读的数据是合理的还是损坏的？如果您可以判断它已损坏，您可以简单地尝试再次读取（希望同时完成将新数据保存到磁盘），但如果您不能判断这真的是一个废话......:-(
我想要记住的教训是，某些持久化数据的方法根本不适合多任务处理目的——下次为程序设计任何类型的数据持久性时，请确保使用更可靠的方法！
瑞克是正确的。您的 Foxpro 设置默认授予 Foxpro 会话对“使用”命令打开的任何表的独占权限。
当您打开表格时，当 VB 应用程序正在运行时，您会被彼此绊倒。
我假设您在 Windows 资源管理器中双击 DBF 文件并打开它们，而不是使用 Foxpro 中的“使用”命令来查看表格。如果您只想这样做，那么（在 VFP 9 中）关闭除一个 VFP 之外的所有会话。转到工具->选项->数据选项卡并取消选中“以独占方式打开”。现在关闭该会话。这将保存设置。下次双击 DBF/DBC 时，它将打开所有具有“共享”访问权限的表。
否则，要使用“use”命令从 VFP 中访问表，请执行以下操作：
独家访问：
use in 0 exclusive <table-file-path>
对于共享访问：
use in 0 shared <table-file-path>
您还可以给它一个 noupdate 标志以使其只读。（查询的安全方式。）
use in 0 exclusive noupdate <table-file-path>
或者
use in 0 shared noupdate <table-file-path>
据我了解，主要问题是 VB 接管了数据库的“独占”权限，并在您打开表（共享或其他方式）时崩溃。
然而，这听起来更像是一个时间问题，而不是 Foxpro 的问题。假设您没有重写 VB 应用程序的访问权限或权限，唯一的另一种选择是找到一个主 VB 应用程序没有运行的时间（可能是深夜？）并运行 Foxpro 查询（. PRG 文件）在调度程序上。查询可以复制到另一个文件，例如 Alex 建议的。
运行 Foxpro 程序的命令很简单：
foxpro <program-name>.prg
这可以放在由通用调度程序运行的 .bat 或 .cmd 文件中。
但是，有一个问题：最好自己从 VFP 中编译 .prg，而不是让 VFP 为您编译它（如果您不这样做，它会这样做。）另外，如果您进行了更改并且不要t 重新编译，VFP 将使用最后编译的版本（只是为了惹恼你。）
如果您已经知道这些东西，请为矫枉过正感到抱歉。
祝你好运。
除了 Ricks 在实际 Foxpro 应用程序中对 SET EXCLUSIVE OFF 的评论。在少数情况下需要对文件进行真正的锁定，例如修改结构、打包数据库（删除标记为删除的记录）、重建索引。如果其中任何一个是锁定文件的基础，那么即使复制也无济于事，因为您将无法获得文件句柄，和/或复制的结果可能不同步，那么您的查询可以失败或给出其他错误结果。
它非常难看，但您可以尝试通过操作系统复制表格，而不是从 Foxpro 应用程序中复制表格。如果操作系统正处于来自另一个进程的写操作的中间，它甚至可能能够处理复制和延迟。一旦你复制，如果有一个 DBC 反向链接到文件并且你无法打开它，你只需要释放表.. DROP 或 FREE，我的记忆让我失望:) 这都是通用的..最好的解决方案是按照建议重新编译锁定 foxpro 软件，使其不是独占的。但是，如果您这样做，那么您必须了解为什么它可能是排他性的……故意的还是只是糟糕的编码？