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

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

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

Re[11]: ADOのコンパイルおよび組み込み

分類:[.NET 全般]　

こんちには。

VBからmdbを作成、操作する際、以下について知識不足でしたので、
どなたかご教授お願い致します。

１．質問１
Microsoft ActiveX Data Object 6.0 Library
Microsoft ADO Ext. 6.0 for DDL and Security
は、Accessをインストールしていない環境
でも問題なく動作しますでしょうか？

２．質問２
又、ユーザリリースする際、
EXEのみ提供する(dllは提供しない)ことで動作させることは可能でしょうか？
現在、模索中で、
コンパイル時に、相互運用型の埋め込み→TRUE、分離→FALSE
にしてEXEを作成していますが確信が持てませんでしたので、
質問させて頂きました。

３．質問３
私の開発環境はADO32bitがインストールされているのですが、
AnyCPU(64bit)でコンパイルすると正常に動作しません。
この場合、64bitのADOを準備してAnyCPUで、
コンパイルすると正常に動作するのでしょうか？

わかりにくい質問で申し訳ございませんでした。
以下経緯によりこのような質問となってしまいました。
申し訳ございません。
①開発環境が社標準で、OS→Windows7 64bit Office→32bitがインストールされており、
思うように検証できない。
②ツールを動作させたい環境は、OS→Windows7 64bit Office→32or64bit
③Accessがインストールされていない環境(ADOが存在しない環境)でも動作させたい
④国内、国外で使用したい。各方面へリリースするので、
できれば、EXEのみでやり取りしたい(DllをExeへ組み込みたい)。

４．質問４
上記を踏まえ私の推測では、64bitのADOのdllを準備し、
相互運用型の埋め込み→TRUE、分離→FALSE、とし、
x86コンパイルすると、32bitOS,64bitOSで動くのではないかと
淡い期待をしているのですが、誤りでしょうか？

以上、宜しくお願いします。

環境
OS:Windows7 64bit
VisualStdioPro:2012 Version11.61030.00 Update4
.NET Framework Version 4.5.50709
ADO関係:32bit用

2015/11/17(Tue) 13:54:48 編集(投稿者)

■No77685 (tarou さん) に返信
mdb 系の話題は久しぶりなので、一部うろ覚えなところもありますが：

> VBからmdbを作成、操作する際、以下について知識不足でしたので、
> どなたかご教授お願い致します。

どのバージョンの mdb をお使いでしょうか?
それによって、使用するドライバー(ミドルウェア)のバージョンも異なってきます。

とはいえ、大抵は 3.5x か 4.0 世代の mdb でしょうから、
基本的には上位バージョンのドライバであれば大丈夫なはずです。
(流石に 3.0 未満のバージョンだと厳しいのですが)

> Microsoft ActiveX Data Object 6.0 Library
> Microsoft ADO Ext. 6.0 for DDL and Security
> は、Accessをインストールしていない環境
> でも問題なく動作しますでしょうか？

動作しない場合もあれば動作する場合もあります。
ADO バージョンと mdb には、直接の関係はありません。

たとえば ADO や Access が入っていなくとも、対応するバージョンの DAO があれば
mdb にはアクセスできます。接続に DAO を用いれば、ですが。

ADO / ADOX の場合、ActiveX Data Object のライブラリがあったとしても、
対応する OLE DB プロバイダも無ければ mdb にはアクセスできません。
実際の運用では、最適化のために JRO もあった方が良いでしょうね。

ADO から利用する場合、mdb 対応プロバイダとしては、私の知るかぎりでは
　"Microsoft.JET.OLEDB.3.51"
　"Microsoft.JET.OLEDB.4.0"
　"Microsoft.ACE.OLEDB.12.0"
　"Microsoft.ACE.OLEDB.15.0"
　"Microsoft.ACE.OLEDB.16.0"
などがあります。
あるいは他社ベンダー製の OLE DB Provider も利用できますが、
現状でも販売し続けているベンダーが残っているのは分かりません。

この他、Access ODBC ドライバーで接続するパターンもあります。
MDAC 2.0 以下には Jet 3.5x 向けのドライバー、
MDAC 2.1/2.5 には、Jet 4.0 向けのドライバーが
同梱されていますが、MDAC 2.6 以上のバージョンには、
Access ODBC ドライバーは同梱されなくなりました。
現行バージョンである MDAC 2.8 および Windows DAC 6.0 も同様です。

> 又、ユーザリリースする際、
> EXEのみ提供する(dllは提供しない)ことで動作させることは可能でしょうか？
そもそも .NET Framework 4.5 は、Windows 7 に同梱されていません。
Windows Update 等などからの追加インストールが必要となります。

同様に、素の Windows 7 には mdb へのアクセス機能は無かったと記憶していますが、
たとえば Access Runtime 等の導入によって、mdb へのアクセスが可能になります。
(どの方法で接続するかによって、必要なライブラリも異なります)

ですから、そういった「依存コンポーネントのインストール」を別途行っても
良いというのであれば、EXE のみでの配布が可能と言えますし、追加のインストールを
許さずに、EXE のみ配置としたいのであれば不可能だという回答になります。

> 私の開発環境はADO32bitがインストールされているのですが、
> AnyCPU(64bit)でコンパイルすると正常に動作しません。

コンパイルエラーなのか、実行時エラーなのか。
あるいはエラーではなく期待動作しない状態なのか。
エラーだとすれば、その内容は何であるのか…現状では判断材料が少なすぎます。
「正常に動作しない」とは、具体的にはどういう状態になってしまうのでしょうか?

もしも x86 ビルドであれば実行できるのであれば、
「32bit 専用の OLE DB Provider で接続しようとしている」
という可能性が高そうです。

> この場合、64bitのADOを準備して
64bit 版の Windows 7 であれば、32/64bit どちらでも ADO が利用できる状態のはずです。

> AnyCPUで、コンパイルすると正常に動作するのでしょうか？
OLE DB Provider は何を用いていますか?

JET プロバイダーは、32bit専用バージョンしか存在しません。
ACE プロバイダーは、32bit専用バージョンと、64bit対応バージョンがあります。

仮に 64bit 対応バージョンを選択していたとしても、
それが導入されていない環境であれば、当然実行できません。

> 開発環境が社標準で、OS→Windows7 64bit Office→32bitがインストールされており、
> 思うように検証できない。
物理でも仮想でも良いので、検証用の環境を用意しましょう。
検証環境の準備にかかるコストも、客先に提示する費用に含めるべき内容です。

> ツールを動作させたい環境は、OS→Windows7 64bit Office→32or64bit
その場合、mdb ではなく accdb を採用し、ACEDAO あるいは ACE Provider で
接続させることをお奨めします。accdb は mdb の後継フォーマットで、
Access 2007 以降で採用された形式です。

なお mdb にしろ accdb にしろ、OLE DB Provider 経由では
呼び出せない機能があります。フル機能を呼び出すためには、
DAO / ACEDAO で接続することになります
(たとえば、OLE DB 経由での accdb の最適化はサポートされていない)。

とはいえ、DAO の Recordset だと、OleDataAdapter.Fill が使えないとか、
COM オブジェクトの ReleaseComObject の手間が煩わしいなどの問題も
あるので、実際には ADO.NET(≠ADODB) と ACEDAO の混在利用も
検討してみると良いでしょう。

> 国内、国外で使用したい。各方面へリリースするので、
> できれば、EXEのみでやり取りしたい(DllをExeへ組み込みたい)。
日本語ランゲージパックを導入していない OS での利用でしょうか?
その場合、mdb / accdb を作成する際の照合順序設定にも気を配って下さい。たとえば、
　;LANGID=0x0411;CP=932;COUNTRY=0
や
　;LANGID=0x00040411;CP=65001;COUNTRY=0
の設定で出荷すると、データベースを開けないといった問題を引き起こします。
https://support.microsoft.com/ja-jp/kb/184988

現在の照合順序設定は、上記のように Access からでも確認できますが、コードからでも
　ADODB の場合：　connection.Properties("Locale Identifier").Value
　DAO の場合：　database.CollatingOrder
で確認できます。(.NET から確認する場合は、これらを ReleaseComObject 対応のコードで記述すべきですが)

※照合順序の変更には、データベースの最適化が必要です。

;LANGID=0x0409;CP=1252;COUNTRY=0 あたりであれば、どの国でも使えますが、
照合順序やフォントセットの違いなどの問題は残るので、検証環境は必須です。

魔界の仮面弁士様、詳しい説明有難うございました。
一通り読ませて頂き、一番、一般ユーザの手間を掛けない、
方法で進めていく予定です。

まずは、質問に対する回答をさせて頂きます。

【回答】
> どのバージョンの mdb をお使いでしょうか?
> それによって、使用するドライバー(ミドルウェア)のバージョンも異なってきます。
Office2010のものですので、14.0.7015.1000 ではないかと思います。

> mdb 対応プロバイダ
"Microsoft.JET.OLEDB.4.0"を使用しています。
社内PCが標準でAccess2010がインストールされている為、
"Microsoft.JET.OLEDB.4.0"を使用した方が、
手間が少なくて済むのではないかと考えていました。
又、所内PCへは、標準で装備されているソフトをインストールできない
ことも理由です。
(他環境は、国内所外、国外)

先の質問では、どこから説明して良いものか焦点が絞れておらず、
ご説明頂いたことで、方向性が見えて参りました。
ありがとうございます。

【質問至った経緯】
今回やろうとしている内容をもう少し、詳しくお伝え致します。
設計の部品(別ソフトによるもの)を、カスタマイズする手法として、
変数にすべての情報を保管して処理を行っていたのですが、
あまりにも、データ量が、莫大な為、変数の変わりにMDBを使用し、
できるだけ、設計側のソフトへのアクセスを減らしたいという、
方針の元、開発を進めていました。

よってMDBの使用目的としては、PUBLIC変数のようなイメージで、
１回の処理で次のように動作させています。
①開始
②既存のMDB(固定ファイル)を削除
③MDBを新規作成
④MDBに設計情報を格納
⑤設計情報のカスタマイズ(Update)
⑥内部処理
⑦終了

【ビルド】
DB操作⇒ADOX、ADODB
プロバイダー⇒"Microsoft.JET.OLEDB.4.0"
ビルド環境⇒Windows7

【動作環境】
OS⇒Windows7 以外特定していない為、
最悪DLLを渡す方法も視野に入れ模索する。

【質問】
一つわからないことがあったのですが、
"Microsoft.JET.OLEDB.4.0"がインストールされていない場合、
DLL等で補うことは可能でしょうか？それとも、Access Runtime 等の導入等
の手間が発生するのでしょうか？もし、DLL等で補えるプロバイダーがあれば、
ご教授頂きたく質問させて頂きました。もしかするとプロバイダーに対する概念が、
間違っているかもしれません。ご了承お願い致します。

以上、宜しくお願い致します。

■No77701 (tarou さん) に返信
>>どのバージョンの mdb をお使いでしょうか?
>>それによって、使用するドライバー(ミドルウェア)のバージョンも異なってきます。
> Office2010のものですので、14.0.7015.1000 ではないかと思います。

説明が下手で済みません。Office ではなく、データベースエンジンのバージョンの事です。

　 1.0　→　Access 1.0
　 1.1　→　Visual Basic 3.0、Access 1.1
　 2.0　→　Visual Basic 3.0 with Compatibility Layer、Access 2.0
　 2.5　→　DAO 2.5/3.51 Compatibility Library、Visual Basic 4.0/16bit、Access 2.0 with Service Pack
　 3.0　→　DAO 3.0、Visual Basic 4.0/32bit、Excel 95(7.0)、Access 95(7.0)
　 3.5　→　DAO 3.5x、Visual Basic 5.0、Access 97(8.0)
　 4.0　→　DAO 3.6、Access 2000(9.0)、2002(10.0)、2003(11.0)
　12.0　→　ACEDao 12.0、Access 2007(12.0)、2010(14.0)、2013(15.0)、2016(16.0)

上記は大雑把な括りであり、実際には Access 2000 製の mdb と 2002/2003 の mdb でも
フォーマットが異なっているなどの差異があるのですが、今回は Access 固有の機能を
必要としているわけでは無いので、今回はそこまで気にしなくても良いでしょう。
3.5 以下で無いと分かれば十分です。

>>mdb 対応プロバイダ
> "Microsoft.JET.OLEDB.4.0"を使用しています。
Jet 4.0 は Service Pack 8 が最後の更新バージョンです。
サポートも既に終了しているため、64bit 版も開発されていません。

新規の開発であれば、accdb や SQL Server Express をお奨めします。
accdb 対応のエンジンであれば、Jet 3.5 以降の mdb にも接続できます。

> 社内PCが標準でAccess2010がインストールされている為、
> "Microsoft.JET.OLEDB.4.0"を使用した方が、
> 手間が少なくて済むのではないかと考えていました。
いえ。Access 2010 が標準で使用するプロバイダは、
"Microsoft.ACE.OLEDB.12.0" です。単体配布版もあります。
https://www.microsoft.com/ja-jp/download/details.aspx?id=13255

> 又、所内PCへは、標準で装備されているソフトをインストールできない
> ことも理由です。
Office 2010 が導入済みなら、ACE (DAO 12.0) の方が素直かと思いますよ。
64bit 対応にもできますし。

ただし、Office の 32bit 版と 64bit 版を同じ環境に入れることはできないため、
32bit 版の Office がインストールされている 64bit 環境の場合は、
x86 ビルドにして WOW64 動作にしておいた方が良いとおもいます。

また、mdb を使うにしろ accdb を使うにしろ、JET/ACE の Service Pack は
最新にしておくようにしましょう。

> DB操作⇒ADOX、ADODB
> プロバイダー⇒"Microsoft.JET.OLEDB.4.0"
VB2012 を選択しているにもかかわらず、ADO.NET ではなく
ADOX や ADODB を選択しているのには、何か理由があるのでしょうか。

COM オブジェクトゆえの「ReleaseComObject」の手間を考えると、
あまり良い選択では無いと思いますが…。
http://support.microsoft.com/kb/321415/ja

仮に、ADO.NET では使えない機能にアクセスしたいというのであれば、
OLE DB 接続ではなく、DAO を使うことをお奨めします。たとえば「最適化」など。

mdb にしろ accdb にしろ、定期的な「最適化」が必須と言えます。。
最適化を行わずに継続運用すると、速度低下や DB 破損を引き起こしやすくなります。

そして最適化を施そうにも、ADODB や ADOX には、最適化の機能が用意されていません。
最適化には、JRO もしくは DAO の「CompactDatabase メソッド」を使う必要があります。
とはいえ、accdb が相手なら DAO 一択なので、普段は ADO.NET で操作するようにし、
それで不足する機能を、DAO で補うといった使い方が良いかと思います。

> 最悪DLLを渡す方法も視野に入れ模索する。
今回の配布先はある程度多岐にわたるようですし、
再頒布可能なモジュールの調査もお忘れなく。

> "Microsoft.JET.OLEDB.4.0"がインストールされていない場合、
> DLL等で補うことは可能でしょうか？
32bitの単体配布版がありますが、Windows 7 世代へのインストールは
保証されていないため、個人的にはお奨めしません。

> よってMDBの使用目的としては、PUBLIC変数のようなイメージで、
> １回の処理で次のように動作させています。
PUBLIC変数のようなイメージ、というのが良く分かりませんが、
設計の良し悪しについては、とりあえず判断保留ということで。

> (他環境は、国内所外、国外)
照合順序の件について。
http://support.microsoft.com/kb/416061/JA/
http://www.naboki.net/access/achell/achell-04.html
https://web.archive.org/web/20090106203940/http://www.massangeana.com/mas/comp/acccoll.htm

魔界の仮面弁士様、詳しいご説明ありがとうございました。

あれから、再度、ご教授頂いた内容を読み直し、
ACEを使用する方向で検討していました。

お教えいただいた内容を参考に、
暫くの間、開発に没頭したいと思います。

大変参考になりました。
ありがとうございます。

最近遭遇した現象に、

１．Windows 8.1 Pro + OFFICE 2013 Personal + ACCESS97形式MDB：ADO / JET からの動作支障なし
２．Windows 8.1 Pro + OFFICE 2013 Professional + ACCESS97形式MDB：ADO / JET から旧形式のMDBサポート外のメッセージ
　　ACCESS から、当該ＭＤＢも、同様のエラーメッセージがでて、開けなかった。
　　⇒Win 8.1 + OFFICE 2013 Personal + ACCSESS 2013 RUNTIME でも、現象発生。

なんてのがあって、凹みました。MDBを、ACCSESS2000以後の形式で対応した様子です。

daive様、ありがとございました。
参考にさせて頂きます。

開発がおよそ完了致しましたので、結果をご報告致します。
ADODBを使用しない方向で実現することができました。

①使用したプロバイダー
"Provider=Microsoft.ACE.OLEDB.16.0;Data Source=" & m_sMdbPath & ";"
"Provider=Microsoft.ACE.OLEDB.15.0;Data Source=" & m_sMdbPath & ";"
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & m_sMdbPath & ";"
"Provider=Microsoft.Jet.OLEDB.4.0;" + "Data Source=" & m_sMdbPath & ";" + "Jet OLEDB:Engine Type=5;"
の何れかで接続できるように作成

②DB、及びテーブル作成
　一部抜粋
Private m_objCat As ADOX.Catalog = Nothing 'ADOX.Catalog
Private m_objDB As Object = Nothing 'ADOX.Catalog.Createにより作成されたDB
Private m_objTbls As ADOX.Tables = Nothing 'ADOX.Tables
Private m_sMDBFilePath As String = "" 'MDBファイルパス
Private m_sEngine As String '接続Engine

m_objCat = New ADOX.Catalog
m_objDB = m_objCat.Create(m_sEngine)

'Tablesオブジェクトの取得
m_objTbls = m_objCat.Tables

～テーブル作成～

'COMの解放
MRComObject(m_objTbls)
MRComObject(m_objDB)
MRComObject(m_objCat)

③DBアクセス
OleDb.OleDbConnectionを使用
　一部抜粋
Private m_oOleDBCon As OleDb.OleDbConnection = Nothing 'Connection
Private m_sEngine As String '接続Engine

m_oOleDBCon = New OleDb.OleDbConnection(m_sEngine)
m_oOleDBCon.Open()

～データアクセス～

m_oOleDBCon.Close()

④ビルド環境
windows7(64bit)にてx86ビルド(開発環境が、32bitのプロバイダーだった為)
※AODXについては、相互運用型の埋め込み⇒TRUE、ローカルコピー⇒FALSE]

最近のWindows環境で、できるだけ動作するに、
私なりに考えたつもりです。
まだ不十分なところもございますが、
後は、エラーが発生したときに都度対応致し、
完成に近づけたいと思います。

魔界の仮面弁士様、daive様、ご指導ありがとございました。

■No77729 (tarou さん) に返信
> "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & m_sMdbPath & ";"
> "Provider=Microsoft.Jet.OLEDB.4.0;" + "Data Source=" & m_sMdbPath & ";" + "Jet OLEDB:Engine Type=5;"

何故、最後の一つだけ、文字列連結に「&」ではなく「+」を使っているのでしょうか?
VB では + で繋ぐことにメリットが無いので、& に変更されることをお奨めします。

ついでに言えば、連結処理がそもそも冗長で、
　"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & m_sMdbPath & ";Jet OLEDB:Engine Type=5;"
あるいは
　"Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=5;Data Source=" & m_sMdbPath
で十分でしょう。

なお、"Jet OLEDB:Engine Type" は、JRO.JetEngine.CompactDatabase メソッドでは意味を持ちますが、
ADODB.Connection.Open や System.Data.OleDb.OleDbConnection.Open メソッドでは無視されるようなので、
接続文字列として指定しても、あまり意味は無いかもしれません。
(開いた後で動的プロパティを見ると、データソースに応じたバージョン値が設定されます)

> 'COMの解放
> MRComObject(m_objTbls)
System.Runtime.InteropServices.Marshal.ReleaseComObject を呼ぶためのメソッドですかね

魔界の仮面弁士
ご指摘ありがとうございました。

>> "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & m_sMdbPath & ";"
>> "Provider=Microsoft.Jet.OLEDB.4.0;" + "Data Source=" & m_sMdbPath & ";" + "Jet OLEDB:Engine Type=5;"
> 何故、最後の一つだけ、文字列連結に「&」ではなく「+」を使っているのでしょうか?
> VB では + で繋ぐことにメリットが無いので、& に変更されることをお奨めします。

&に変更させて頂きました。

> ついでに言えば、連結処理がそもそも冗長で、
> 　"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & m_sMdbPath & ";Jet OLEDB:Engine Type=5;"
> あるいは
> 　"Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=5;Data Source=" & m_sMdbPath
> で十分でしょう。

こちらも変更させて頂きました。

> なお、"Jet OLEDB:Engine Type" は、JRO.JetEngine.CompactDatabase メソッドでは意味を持ちますが、
> ADODB.Connection.Open や System.Data.OleDb.OleDbConnection.Open メソッドでは無視されるようなので、
> 接続文字列として指定しても、あまり意味は無いかもしれません。
> (開いた後で動的プロパティを見ると、データソースに応じたバージョン値が設定されます)
"Jet OLEDB:Engine Type"の接続文字列は、消去させていただきました。
接続文字列について意味がよくわかっていませんでした。ご説明有難うございます。

>> MRComObject(m_objTbls)
> System.Runtime.InteropServices.Marshal.ReleaseComObject を呼ぶためのメソッドですかね
ご指摘の通りです。説明不足でした。申し訳ございません。
以下がその関数ですが、見ようみまねで、作成したものです。
引数がByref、Byval どちらが妥当なのか等、まだまだ、私の中ではすっきりと、
解決できていません。そもそも関数にしてよいのかも、正直迷っています。

Public Shared Sub MRComObject(ByRef objCom As Object)
'COM オブジェクトの使用後、明示的に COM オブジェクトへの参照を解放する
Try
'提供されたランタイム呼び出し可能ラッパーの参照カウントをデクリメントします
If Not objCom Is Nothing AndAlso System.Runtime.InteropServices. _
Marshal.IsComObject(objCom) Then
Dim I As Integer
Do
I = System.Runtime.InteropServices.Marshal.ReleaseComObject(objCom)
objCom = Nothing
Loop Until I <= 0
End If
Catch
Finally
'参照を解除する
objCom = Nothing
End Try
End Sub

もし、宜しければご教授頂けないでしょうか。

■No77751 (tarou さん) に返信
>>> MRComObject(m_objTbls)
これは元々、
　https://support.microsoft.com/ja-jp/kb/317109
で公開されている NAR メソッドが元になっています。

> そもそも関数にしてよいのかも、正直迷っています。
> Public Shared Sub MRComObject(ByRef objCom As Object)
その実装だと、「Option Strict On」の時に利用できなくなってしまいます。
下記の MRComObject 実装を参照してみて下さい。
http://hanatyan.sakura.ne.jp/dotnet/Excel01.htm

魔界の仮面弁士様ありがとうございます。

大変わかりやすく、今まで、不透明だった内容が、
明るくなりました。
ありがとうございました。

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

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

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

Re[11]: ADOのコンパイルおよび組み込み

過去ログには書き込み不可