現在A機とB機でLANを組んで作業を分担させるVB6PGMのテストをしています。
A機にACCESSのmdbファイルが有りODBCで参照します。
B機はリモートドライブ共有でA機のmdbファイルに接続しODBCで参照してます。
作業順は
１．B機のVB6からRDOでDBに計算用データを登録後コミットで確定し、直後にwinsock(TCP)にてA機に作業終了の連絡をいます。
２．その連絡を受けA機がDB内のデータを基に計算をして結果をDBに入れてコミットし、今度はB機に連絡を入れます。
３．連絡を受けたB機がDB内を検索し、結果を画面に書き出します。
という流れを繰り返します。
問題は、それぞれコミット後に相手に連絡をいれ相手がDBを読み込むのですが、その情報が一部最新情報になっていません。(コミットが出来ていないように見える)
確認して分かったことは
１．連絡を受けて0.3秒後ぐらいまでは以前に取ってきた古い情報がえられます。
0.3〜1.0秒後は不安定です。(新旧が不確定)
1.0秒後からは新データのようですが、確実でない場合がまれにあります。
２．DBが書込み確定できていないのかと思い、コミット後にDBコネクトを切断し、直ぐ再度コネクトをしてから連絡してみましたが、結果は同じでした。
３．既存の読込みバッファがあればそれを使用してしまうかと思い、連絡受信後DBコネクトを切断し、直ぐ再度コネクトしてからDBにアクセスするとうまく行きました。
以上で原因は、なんとなく分かったのですが、今の対策処理ではDBの接続切断を繰り返すという、あまりやりたくない結果です。
DB読込み時に強制的に再度DBを見に行く設定を探しましたが見つかりません。
ちなみに現在の読み込む設定は
    Set RDOキー = RDOコネクション.OpenResultset("SQL文", , , rdExecDirect)
    RDOキー .MoveNextとRDOキー .EOF
を使って情報を得ています
ODBCのパラメータを色々変更してもダメでした。何か言い知恵があればご教授をお願いします。
長文にて失礼いたしました。

> 現在A機とB機でLANを組んで作業を分担させるVB6PGMのテストをしています。
> A機にACCESSのmdbファイルが有りODBCで参照します。
> B機はリモートドライブ共有でA機のmdbファイルに接続しODBCで参照してます。

　　なぜまだVB6？
　　なぜODBC？
　　なぜRDO？

　　突っ込みどころ満載というか・・・

> ODBCのパラメータを色々変更してもダメでした。何か言い知恵があればご教授をお願いします。

　　ないものねだりかと・・・
　　速度面だけなら、DAOの方が早いかも。
　　（わざわざ一番遅いODBC使っているんだからどうしようもない）
　　ただ、ネットワーク経由の共有は、非常に怖い・・・
　　MDB壊す危険が十分にあると思います。

　　よって・・・

　　VB6のままなら、ACCESSのMDBを、MSDE2000/SQL Server 2005 Express
　　SQL Server 2008 Expressに変更して、ADOで行う。

　　VB.NETに変更できるなら、ADO.NETのSqlDependencyを使えば、Insert/
　　Delete/Updateの変更イベントを取得できるので、わざわざSokcet通信は
　　必要ない。

　　というところでしょうか・・・

以上。参考まで

早速のご回答ありがとうございます。

ご指摘の件、すべて認識しておりますが、多くの既存のPGMや管理の人材等で過去の遺物を引きずらなくてはいけない現状もお察し下さい。

ちなみに、その後少し早いマシンで環境を作成し同一の条件でテストをすると、DBをクローズ後再度オープンしてもエラーの現象が起きました。

うまく行ったのは遅いマシンでは単にクローズオープンに時間がかかっていただけのようです。

また、DB2＋DB2ODBCでは、この問題は起こりませんでした。

恐るべし ACCESS ODBC DRIVER です。

> ちなみに、その後少し早いマシンで環境を作成し同一の条件でテストをすると、DBをクローズ後再度オープンしてもエラーの現象が起きました。
>
> うまく行ったのは遅いマシンでは単にクローズオープンに時間がかかっていただけのようです。
>
> また、DB2＋DB2ODBCでは、この問題は起こりませんでした。

　　いや・・・他社のものは他社の設計思想で作られているんで、参考には
　　なりません。じゃ〜MDBをDB2にすれば？確かDB2もフリー版あったよう
　　に思いますが。

●　http://www.canalian.com/workshop/access/JetCache.html

　　方法はあるようですが、ODBCでもRDOでも無い・・・
　　せめて、全てADOで書いていれば、後、ADO.NETへの移行も少なからず
　　楽・・・

以上。参考まで

お世話になります。
出張中で返事が遅くなり申し訳ありませんでした。

> 　　せめて、全てADOで書いていれば、後、ADO.NETへの移行も少なからず
> 　　楽・・・

おっしゃられるとおり今後ADOへと変更していくように提案中です。
余談ですが、RDOほどではなくても古い人も多くDAOを押してくる人が多いです。
ADOは機能が少ないなどと・・・
マルチアクセスを考えるとADOしかないと孤軍奮闘しております。

ご意見ありがとうございました。
完了とさせていただきます。