我在写一个小软件，它将成为使用dbf foxpro表的现有应用程序的一部分。我的应用程序只是读取2个表格填充数据集并关闭连接，非常快速和简单。它一直运行，直到其中一个表被使用，或者由foxpro本身（当表被打开时）或主应用程序访问该表时。阅读另一个应用程序正在使用的Foxpro表
当它发生在一个得到异常
EX = { “无法打开文件：C：\ DATA \ myFile.dbf”}错误码= -2147217865
是否可以指定我想访问它只是为了阅读，而不是编辑？ PS：我使用VS 2008 C＃来访问它。我的连接字符串的样子：“供应商= VFPOLEDB.1;数据源= C：\ DATA \”
非常感谢
当你提到“FoxPro本身”时，我假设你的意思是有人正在为DOS或Windows或Visual FoxPro（任何版本）运行FoxPro 2.6。如果是这种情况，请确保用户在命令中使用以下命令窗口
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驱动程序遵循运行时标准。
里克Schummer VFP MVP
你得到的错误代码是HRESULT 0x80040E37的错位由没有按一些中间步骤不知道未签名的int32's - 这是“无法打开该表”的通用ODBC错误（通常是由于错误拼写）。毫无疑问，Foxpro和主应用程序正在使用的库正在做某种“锁定” - 即使ODBC允许您指定您只想读取，但如果某些其他进程已打开写入，它仍应被拒绝（两个或更多的流程只是想读就可以，但即使只有一个想写的流程也必须排除所有其他人，读者或作者）。
如果您在短暂读取时不能暂时从其他用途中分离.DBF文件，那么可能会将其复制到另一个名称（仍然是.DBF），然后尝试打开该副本 - 执行它工作，还是失败，同样的错误？在后一种情况下，可能有办法破解文件，以便清除它的“锁定状态” - 只要它没有被使用（因为复制不会，直到你打开它！）。完成读取后，您可以删除副本。
问题是，这种方法虽然可能会起作用，但不会完全可靠：它可能是（如果您不幸），foxpro或您的主应用程序可能正在进行更改到数据库（这就是为什么他们会锁定它 - 毕竟为了安全起见，他们可以进行更改），并且在您执行复制的那一刻，更改可能会部分但不完全提交到磁盘。你有办法检查你正在阅读的数据是否合理或损坏？如果你可以告诉它已经损坏，你可以简单地尝试再读一遍（希望将新数据保存到磁盘的同时完成），但是如果你不能说这真的是一堆废话... :-(
I猜测要保留的教训是，保持数据的某些方法根本不适用于多任务处理的目的 - 请确保在下一次为您的程序设计任何类型的数据持久性时使用更可靠的方法！
除了在实际的FoxPro应用程序的SET EXCLUSIVE OFF里克斯评论。有几个实例需要对文件进行真正的锁定，例如修改结构，打包数据库（删除标记为删除的记录），重建索引。如果其中任何一个是锁定文件的基础，那么即使复制也无济于事，因为您无法获取文件句柄，并且/或者复制的结果可能不同步，那么您的查询可能会失败或给出其他错误结果。
瑞克是正确的。您的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文件去。
但是，有一个问题： 自己编译.prg总是比较好，而不是让VFP为你编译它（如果你不这样做的话）。一个变化，不要重新编译，VFP将使用最后编译的版本（只是为了贬低你）。
如果你已经知道这个东西，对于矫枉过正的对不起。
祝你好运。
这是非常丑陋的，但你可以尝试通过操作系统与FoxPro应用程序内复制表。如果操作系统处于另一个进程的写入操作的中间，操作系统甚至可以处理复制和延迟。一旦你复制，如果有一个DBC反向链接到文件，你不能打开它，你只需要免费的表.. DROP或FREE，我的记忆失败了我:)这一切都意味着通用..最好的解决方案是按照建议重新编译锁定foxpro软件，以便它不是唯一的。但是，如果你这样做，那么你必须明白为什么它可能是独家开始......故意或只是错误的编码？
如果另一个程序通过独占使用或FLOCK（）命令对表进行锁定，如何分离DBF？如果该文件正在被另一个程序使用，它将不允许任何打开或分离。 – 2009-07-28 03:06:16
我不知道Foxpro是否使用咨询锁（您可以在CopyFile中忽略）或不可破解的锁（您不能），但即使在后一种情况下也可能有解决方法（例如“外部”文件系统被配置为不执行牢不可破的锁），总是与我已经给出的警告当然。 – 2009-07-28 04:03:28