C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

JRO を利用して READ キャッシュを更新

分類:[Microsoft Office 全般]　

Access VBA で調べていてこちらに辿り着いた者です。場違いであれば申し訳ありません。

VB に詳しい皆様の間で、Jet エンジンでの多人数同時使用のために
JRO を利用して READ キャッシュを更新するというノウハウがおありだと知りました。
それで私も早速やってみようと参照設定して以下を実行したのですが、
Set je = New JRO.JetEngine
で「クラスが登録されていません」となって進みません

当方の環境は Windows 10 64 ビット + Access 2019 64 ビットです。
C:\Program Files (x86)\Common Files\System\ado\msjro.dll
があるのは確認しましたが、32ビット版だからだめだということでいいのでしょうか。
"msjro.dll 64 bit" で検索しましたがよく判らず、助けていただければ幸いです。
よろしくお願いします。

■No102614 (eb さん) に返信

JET は 32-bit 版しかないので、64-bit で動いているアプリからは使えないという
話ではないのでしょうか？

その場合エラーメッセージが「プロバイダーが登録されていません」というような
エラーメッセージになるはずなので違うかもしれませんが・・・

WebSurfer 様、レスありがとうございます。

あいまいですみません。
接続は Microsoft.ACE.OLEDB.16.0 にしていて、
ここについてはエラーは出ません（という話でいいでしょうか）。

READ キャッシュの更新については DAO ではできるようなので、
Access だけで「厳密な」多人数同時利用をしようとしたら
DAO（ACEDAO）一択になったということなのでしょうか。
Microsoft が古い ADO のサポートを辞めたい、のような。

■No102614 (eb さん) に返信
> それで私も早速やってみようと参照設定して以下を実行したのですが、
> Set je = New JRO.JetEngine
> で「クラスが登録されていません」となって進みません

そのファイルがあった場所は
　C:\Program Files (x86)\Common Files\System\ado\msjro.dll
ではありませんでしたか?

Vista / Server 2008 以降での JRO の利用は推奨されていなかったと思いますし、
そもそも 64bit 版の JRO が提供されたという話も、私は聞いたことがありません。
32bit 環境であれば、現在も使用可能ですけれどね。

> VB に詳しい皆様の間で、Jet エンジンでの多人数同時使用のために
> JRO を利用して READ キャッシュを更新するというノウハウがおありだと知りました。

JRO の JetEngine.RefreshCache メソッドのことを指しておられるのですよね。
https://learn.microsoft.com/en-us/previous-versions/office/developer/office-2007/bb237216%28v%3doffice.12%29?WT.mc_id=DT-MVP-8907

どのバージョンの Microsoft Access をお使いなのかは分かりませんが、
現行バージョンにおいては、あえて OLE DB Provider を使う必要は無いと思いますよ。
Access VBA なら、DAO(ACEDAO も含む) の方が融通が利くと思いますし、
パフォーマンス面でも DAO の方が有利かと。

CurrentProject.Connection との併用ならば、JRO が使われることもありますが、
CodeDb や CurrentDb を使っているのであれば、単に DAO.Recordset を開く前に
「DBEngine.Idle dbRefreshCache」を呼び出すだけで済みますので、
JRO を追加で参照設定する意味がありません。

(1) JET の Read キャッシュを強制更新するには(Read キャッシュの内容を強制的にディスクから読み込みなおす)
　DAO ならば DBEngine.Idle dbRefreshCache
　ADO ならば、JRO.JetEngine の RefreshCache メソッド
　※既定の Read キャッシュ更新間隔は 5000 ミリ秒

(2) JET の Write キャッシュによる書き込み遅延を防いで同期的に書き込みを行わせるには
　暗黙トランザクションを用いず、常に明示的なトランクザクションを使えばよい。
　すなわち BeginTrans / CommitTrans メソッドを常に利用するようにする。
　※暗黙トランザクションによる非同期書き込みの場合、既定の書き込み遅延時間は 500 ミリ秒

(3) OS の Write キャッシュをバイパスして、ディスクに直接書き込みを行わせるには
　DAO ならば、DBEngine.Workspaces(0).CommitTrans dbForceOSFlush
　ADO ならば、CurrentProject.Connection.Properties("Jet OLEDB:Transaction Commit Mode").Value = 1
　※Write キャッシュをバイパスすると書き込みパフォーマンスが犠牲になるため、常時有効化することはお奨めしません。

日曜日でお休みのところ、丁寧なレス恐れ入ります。
魔界の仮面弁士様のご投稿を見てこちらに伺ったのが経緯なので、
ご本人が来て下さって感慨深いです。
（canalian.com の記事もそうだったのでしょうか）。

>そのファイルがあった場所は
>　C:\Program Files (x86)\Common Files\System\ado\msjro.dll
>ではありませんでしたか?

はい、そうです。そして C:\Program Files\Common Files には見当たらず……

>Access VBA なら、DAO(ACEDAO も含む) の方が融通が利くと思いますし、
>パフォーマンス面でも DAO の方が有利かと。

そうなんですね。個人的には ADO のほうが重要な技術だと思い込んでいました。

お返事は個人的な勉強ファイルに保存させていただきます。
本当にありがとうございました。

■No102618 (eb さん) に返信
> 魔界の仮面弁士様のご投稿を見てこちらに伺ったのが経緯なので、
何処の投稿をご覧になったのかは分かりませんが、確かに過去に何度か紹介した覚えがあります。
ただ、Access VBA 特化のフォーラムが激減しているので、
最近は書いていないはずですし、紹介したサイトももう閉鎖しているんじゃないかな…?

> （canalian.com の記事もそうだったのでしょうか）。
あの記事を書いたのは私では無く、葛西邦生さんですね。長らくお会いしていないですけれど。

>> Access VBA なら、DAO(ACEDAO も含む) の方が融通が利くと思いますし、
>> パフォーマンス面でも DAO の方が有利かと。
> そうなんですね。個人的には ADO のほうが重要な技術だと思い込んでいました。
ADO が RDO や DAO の後継であることは確かですし、
異種データベース接続のインターフェイスという点においては ADO に軍配があがります。

一方、接続に必要なレイヤー数の違いといった要因により、
特定のデータベースに向けては、汎用ミドルウェアよりも
専用ミドルウェアの方が、パフォーマンスや機能面で有用なこともあります。
ミドルウェアによって、使用できる SQL 構文が微妙に異なる場合があるのが悩ましいところですが。

DAO → Jet → Access Database
RDO → ODBC → Jet → Access Database
ADO → OLE DB → Jet → Access Database
ADO → OLE DB → ODBC → Jet → Access Database

また、歴史的な事情から、データベース側のバージョンによって、
適切なミドルウェアが変化することもあります。

対 SQL Server に関しても、従来の SQLOLEDB や SQL Server Native Client による接続から
MSOLEDBSQL や ODBC による接続に切り替えるようアナウンスされていたりします。
https://learn.microsoft.com/ja-jp/sql/relational-databases/native-client/applications/using-ado-with-sql-server-native-client?WT.mc_id=DT-MVP-8907

個人的には、 Access VBA に限定していえば、ADO を使うことは少なくて、
もっぱら DAO を利用しています。(VB.NET などから利用する場合は、また別ですよ)

実際、後継バージョンでは ADODB が既定で参照されていなかったりもしていますし。
https://dxr165.blog.fc2.com/blog-entry-115.html

対 Access に限定して、「ADO にできて DAO にはできないこと」って何があるかな…。
　Debug.Print CurrentProject.Connection.Properties("Jet OLEDB:Compact Reclaimed Space Amount").Value
とかですかね。他にもあるかもしれませんが、ちょっと思い出せません。

逆に、ADO にできなくて DAO ならばできることと言えば、昔からの CreateProperty などが挙げられます。
新規データベースの作成などもそうですし(ADO の場合は ADOX の支援が必要)、
今回話題に挙げられた RefreshCache もそうですね(ADO の場合は JRO の支援が必要)。CompactDatabase もかな。

一方、レジストリベースで設定される個所については、共通して利用できるかと。
ただ、C2R (ClickToRun) の登場などもあり、レジストリの場所は変化しているのが厄介です。
実行計画を調べるための JETSHOWPLAN とか、今でも使えるんだろうか…?
https://support.microsoft.com/ja-jp/office/8cc7bad8-38c2-4a7a-a604-43e9a7bbc4fb?WT.mc_id=DT-MVP-8907
https://social.msdn.microsoft.com/Forums/office/en-US/b786a029-fa8c-4556-a40c-e749ba73499e/jetshowplan-in-access2013

Access 関連で個人的に困っているのが、ISAMStats 関連。

従来の環境だと、こんな感じで取得できたのですが、
最近の環境だと、ADO でも DAO でも拾えなくなってしまっていて。

Debug.Print DBEngine.ISAMStats(0), "ディスク読取数"
Debug.Print DBEngine.ISAMStats(1), "ディスク書込数"
Debug.Print DBEngine.ISAMStats(2), "キャッシュからの読取数"
Debug.Print DBEngine.ISAMStats(3), "キャッシュからの読取数"
Debug.Print DBEngine.ISAMStats(4), "配置されたロック数"
Debug.Print DBEngine.ISAMStats(5), "解除されたロック数"
'以下は、JET 4.0 (DAO 3.6)環境で有効
Debug.Print DBEngine.ISAMStats(6), "レコードに記憶されたLVS数"
Debug.Print DBEngine.ISAMStats(7), "共有ページに記憶されたLVS数"
Debug.Print DBEngine.ISAMStats(8), "排他ページに記憶されたLVS数"
Debug.Print DBEngine.ISAMStats(9), "LVSのページ数"
Debug.Print DBEngine.ISAMStats(10),"レコードから移動されたLVS数"
Debug.Print DBEngine.ISAMStats(11),"未使用のロード済みページ数"
'事前に「DBEngine.ISAMStats 番号, True」を呼ぶと、各統計値がリセットされる

'ADO で取得する場合
Set Rs = Cn.OpenSchema(adSchemaProviderSpecific, , "{8703b612-5d43-11d1-bdbf-00c04fb92675}")
' 統計値のリセットは、OpenSchemaの実行前に、あらかじめ下記を呼ぶ
' Cn.Properties("Jet OLEDB:Reset ISAM Stats").Value = True　'False:蓄積、True:リセット

>>魔界の仮面弁士様のご投稿を見てこちらに伺ったのが経緯なので、
> 何処の投稿をご覧になったのかは分かりませんが、確かに過去に何度か紹介した覚えがあります。
> ただ、Access VBA 特化のフォーラムが激減しているので、
> 最近は書いていないはずですし、紹介したサイトももう閉鎖しているんじゃないかな…?

今確認しましたが、「VB2.0～VB6.0用掲示板のログNo.1」2002/11/19 が初出でしょうか。
そしてあちらがあいにくサーバ証明書に問題があるようでこちらに……という次第です。
20 年以上前に書き込まれた方とお話しできているのが感慨深いです。

>>（canalian.com の記事もそうだったのでしょうか）。
> あの記事を書いたのは私では無く、葛西邦生さんですね。長らくお会いしていないですけれど。

canalian.com で伝わったのが驚きであり驚きでないです！
ちなみに canalian 様のほうでは、dbForceOSFlush について、
「このような指定が有効なのは、Windows OSに対してだけ」とも拝見しました。
想像するに、
「Access 同時利用で遅延を無くしたければ Windows Server を買うしかない」
「そうすれば無料で MSDE も利用できる。Access から簡単にアップサイジングできる」
ということで、SQL Server に移行した会社も少なくなかったのでしょうね。
私は小さな事務所の IT 担当者で、廉価な Linux NAS を使っていますが、
上司にそういうことを話す機会も来そうです。

他、私には過剰な（笑）質と量の情報をありがとうございます。
市販の Access 本を普通に超えていて興味深いです。
Access でも実行計画が見られる（見られた）とは、初めて知りました。
また何かあった時に相談させていただければ幸いです。

■No102621 (eb さん) に返信
> 今確認しましたが、「VB2.0～VB6.0用掲示板のログNo.1」2002/11/19 が初出でしょうか。
VB レスキュー掲示板の前にも、VB 系 Mailing List に書いてたかもしれない。

> そしてあちらがあいにくサーバ証明書に問題があるようでこちらに……という次第です。
済みません。それ半分は、提案した私のせいかも。(汗
昨日から発生したエラーなので、ちょっとタイミングが悪かったですね。

証明書の COMMON NAME INVALID エラーを無視すれば、一応繋がります。
証明書の問題というよりは、サーバーの設定の問題かと思いますが、解決にはもう少し時間がかかりそう。
※事情については、あちらの 24日(金)のスレッド No.16670 を参照

■No102622 (魔界の仮面弁士さん) に返信
>>そしてあちらがあいにくサーバ証明書に問題があるようでこちらに……という次第です。
> 済みません。それ半分は、提案した私のせいかも。(汗
> 昨日から発生したエラーなので、ちょっとタイミングが悪かったですね。

あちらの証明書エラーは、本日27日の15時に回復したようです。

>済みません。それ半分は、提案した私のせいかも。(汗
>昨日から発生したエラーなので、ちょっとタイミングが悪かったですね。

ピンポイントで遭遇した私の運の悪さが問題なのかと（苦笑）。
ところで、「解決したらチェック」というシステムがあるのですね。
解決済みにさせていただきます、ありがとうございました。

名前 (*必須)
E-Mail (任意)
Web サイト (任意)
投稿モード	通常モード　　図表モード (ソースコードを貼る場合はこちらを使用)
本文　(質問の場合は、開発環境・使用言語のバージョンなどを最初に書いてください) ■No102626 (eb さん) に返信 > >済みません。それ半分は、提案した私のせいかも。(汗 > >昨日から発生したエラーなので、ちょっとタイミングが悪かったですね。 > > ピンポイントで遭遇した私の運の悪さが問題なのかと（苦笑）。 > ところで、「解決したらチェック」というシステムがあるのですね。 > 解決済みにさせていただきます、ありがとうございました。
編集キー	自分の投稿を編集する時に必要です (半角8文字以内)
解決済み /解決したらチェックしておきましょう。
プレビュー/