dbf foxpro テーブルを使用する既存のアプリケーションの一部となる小さなソフトウェアを作成しています。私のアプリケーションは、データセットを埋める 2 つのテーブルを読み取り、接続を閉じるだけで、非常に高速でシンプルです。これらのテーブルの 1 つが使用されるまで、または foxpro 自体 (テーブルが開かれるとき) またはメイン アプリケーションがそのテーブルにアクセスするときまで機能します。
それが発生すると、例外が発生します
ex = {"ファイル c:\data\myFile.dbf を開けません。"} ErrorCode = -2147217865
編集ではなく、読み取り専用にアクセスするように指定することはできますか?
PS: VS 2008 C# を使用してアクセスしています。私の接続文字列は次のようになります: "Provider=VFPOLEDB.1;Data Source=C:\data\"
どうもありがとう
I am making an assumption when you are referring to "FoxPro itself" you mean someone is running FoxPro 2.6 for DOS or Windows, or Visual FoxPro (any version). If this is the case make sure the user uses the following command in the Command Window
SET EXCLUSIVE OFF
Or they can open each table and include the SHARED clause on each USE command.
If you are referring to an application developed in FoxPro running against the data you have a slightly more complex situation because the app could be designed to be single user and have a SET EXCLUSIVE ON in the code. The best shot you have in this case is to try modify an existing Config.FP or Config.FPW (depending on the version) and adding a line:
EXCLUSIVE = OFF
Or you can create the file if it does not exist. If that does not work you would need the application source code to change it so it does not open tables exclusively.
As for your use of the VFP OLE DB driver with your C# program, you can include a Config.FPW file in the folder with the EXCLUSIVE = OFF and it will ensure you open the files in shared mode, just in case you are attempting exclusive use. This unlikely since the runtime version does not default to exclusive being on and the OLE DB driver is following the runtime standard.
Rick Schummer VFP MVP
リックは正しいです。Foxpro の設定はデフォルトで、Foxpro セッションに「use」コマンドで開いたすべてのテーブルに排他的な権限を与えるようになっています。
テーブルを開いているとき、VB アプリが実行されている間、お互いにつまずきます。
Windows エクスプローラーで DBF ファイルをダブルクリックして開き、Foxpro で "use" コマンドを使用してテーブルを表示していないと仮定しています。その方法だけを実行したい場合は、(VFP 9 で) VFP の 1 つを除くすべてのセッションを閉じます。[ツール] -> [オプション] -> [データ] タブに移動し、[排他を開く] のチェックを外します。そのセッションを閉じます。これで設定が保存されます。次に 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 ファイル) をスケジューラで実行します。アレックスが提案したように、クエリは別のファイルにコピーできます。
Foxpro プログラムを実行するコマンドは簡単です。
foxpro <program-name>.prg
これは、汎用スケジューラによって実行される .bat または .cmd ファイルに入れることができます。
ただし、キャッチがあります。VFP にコンパイルさせるよりも、VFP 内から .prg をコンパイルする方が常に良いです (そうしないとコンパイルされます)。再コンパイルしないと、VFP は最後にコンパイルされたバージョンを使用します (悪意があります)。
このことをすでに知っていた場合は、やり過ぎで申し訳ありません。
幸運を。
あなたが得ているエラーコードは HRESULT 0x80040E37 で、署名されていない int32 について知らないいくつかの中間ステップによって壊れています。これは、「そのテーブルを開けません」という一般的な ODBC エラーです (通常はスペルミスによる)。Foxpro とメイン アプリが使用しているライブラリが何らかの「ロック」を行っていることは間違いありません。ODBC で読み取りのみを指定できたとしても、他のプロセスが書き込み用に開いている場合は拒否する必要があります。 (2 つ以上のプロセスが読みたいだけなら問題ありませんが、書きたいプロセスが 1 つだけでも、他のすべてのリーダーまたはライターを除外する必要があります)。
.DBF ファイルを簡単に読み取っている間、他の用途から一時的に切り離すことができない場合、別の名前 (.DBF のまま) にコピーして、そのコピーを開こうとするのが 1 つの方法かもしれません。それでも同じエラーで失敗しますか? 後者の場合、ファイルをハッキングして「ロックされた状態」を消去する方法があるかもしれません-使用されていない限り（コピーが使用されない限り、それを開くことができるまで!-）。必要な読み取りが完了したら、コピーを削除できます。
問題は、このアプローチは機能するかもしれませんが、完全に信頼できるわけではないということです:フォックスプロまたはメインアプリが DB に変更を加えている最中である可能性があります (それが理由です)。結局のところ、彼らはそれをロックしています-安全のために変更を加えることができます)、コピーを実行した瞬間に変更が部分的にディスクにコミットされているわけではありません。読み取っているデータが適切か破損しているかを確認する方法はありますか? 破損していると判断できる場合は、単純に再度読み取りを試みることができます (ディスクへの新しいデータの保存がその間に完了していることを願っています)。
覚えておくべき教訓は、データを永続化する特定の方法は、マルチタスクの目的にはまったく適していないということだと思います。次にプログラムのデータ永続化を設計するときは、より確実な方法を使用してください!
かなり醜いですが、Foxpro アプリ内からではなく、OS 経由でテーブルをコピーしてみてください。OS は、別のプロセスからの書き込み操作の最中であれば、コピーを処理して遅延させることさえできるかもしれません。コピーしたら、ファイルへのDBCバックリンクがあり、それを開くことができない場合は、単にテーブルをFREEする必要があります.DROPまたはFREE、私の記憶は私を失敗させます:)これはすべて一般的なものです..最善の解決策は、排他的ではないように、提案されているようにロック foxpro ソフトウェアを再コンパイルすることです。しかし、それを行う場合、最初から排他的であった理由を理解する必要があります..意図的なのか、それとも単に悪いコーディングなのか?
実際の Foxpro アプリケーションでの SET EXCLUSIVE OFF に関する Ricks のコメントは別として。構造の変更、データベースのパッキング (削除対象としてマークされたレコードの削除)、インデックスの再構築など、ファイルの真のロックが必要な場合がいくつかあります。それらのいずれかがロックされたファイルの基礎である場合、ファイルハンドルを取得できないためコピーしても役に立たない、および/またはコピーの結果が同期していない可能性があるため、クエリは可能性があります失敗するか、他の誤った結果を与える。