webdevqa.jp.net

Access 2007でADOまたはDAOを使用する方が良いですか?

Access 2007で新しいデータベースを作成する場合、ADO(ActiveXデータオブジェクト)またはDAO(データアクセスオブジェクト)を使用する必要がありますか?

編集:このデータベースの一部は、Excel2007スプレッドシートからデータをインポートします。

20

[記録として、かつては「Jet」であった正式名称は、現在は「Accessデータベースエンジン」になっています。]

ACE(Access2007エンジンの.accdb形式)機能の場合は、ACEDAOである必要があります。

Jet 4.0の機能の場合、ADOクラシックである必要があります。

Jet 3.51以前の機能の場合、ADOまたはDAOのいずれかを選択します。両方に長所と短所があります。Accessデータベースエンジン機能の大部分は両方に共通です。相互に排他的な機能は議論の余地があります。 。ライフスタイルの選択かもしれませんが、大したことではありません。スマートコーダーは両方の長所を使用します:)

私はかなり両方を使用しましたが、ADOは私の個人的な好みです。DAOよりも近代的であるため、アーキテクチャ的には改善されています。よりフラットなオブジェクトモデルであり、DAOの分解の問題はありません。 、など。より多くのプロパティとメソッド、およびイベントの導入(DAOにはありません)。たとえば、非同期接続やレコードのフェッチなど。ADOレコードセットは切断、階層化、作成できますが、DAOレコードセットはできません。基本的にはDAOの良いところを取り入れて、より良くしました。

DAOには長所があります。 1つは、Access/JetのADOよりも多くのDAOコード例があります。

P.S.どういうわけか、DAOが好きな人は本当にADOが嫌いです。宣伝は無視してください。 ADOは非推奨ではありません。ACEにはOLE DBプロバイダーがあり、現在64ビットでACEを使用する唯一の方法です。ADO.NETにはありません。置き換えられたADOクラシックは、AccessプロジェクトでVB.NETがVBA6に取って代わった以上のものです。

編集:明確にするために、「Jet4.0機能の場合はADOクラシック」である必要があります。これは、DAO3.6がJet4.0の新機能に対していくつかの拡張機能しか受けていないためです。スケール/精度を指定できないDECIMALデータ型。他の機能はDAOから完全に欠落しています。たとえば、Jet 4.0でDAO(またはACEのACEDAO)を使用して次のことを実行できますか?

CREATE TABLE Test (
   col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL, 
   CHECK (NOT EXISTS (
                      SELECT T1.col1 
                        FROM Test AS T1 
                        WHERE T1.col1 <> '0000' 
                        GROUP 
                           BY T1.col1 
                       HAVING COUNT(*) > 1
                      ))
);

(ヒント:テーブルレベルのデータ整合性制約のある圧縮可能な固定幅のテキスト列。)いいえ、できません。

AFAIK ACEDAOの唯一の機能強化は、新しいACE機能のためでした。つまり、DAOのJet4.0のギャップを埋めることはありませんでした。そして、なぜ彼らはすべきですか?ギャップを埋めるためにADOがまだあります。チームが、厄介なDECIMALソートのバグを修正するなど、より生産的に時間を費やしたほうがよいでしょう。私にとってACEの最も良い点は;- )

15
onedaywhen

ここで推奨されるテクノロジーはDAOです。 ADOは大幅に減価償却されており、現在ADO.netに置き換えられています。

DAOは、MS Accessを使用するためのネイティブで推奨されるデータオブジェクトモデルであるだけでなく、引き続き拡張されており、SharePoint用の多数の新機能を備えています。 Access 2007では、SharePointリストがサポートされるようになりました。これは、2007年の新しいDAOオブジェクトモデルにより、SharePointリストをSQLサーバーテーブルとして使用および表示できることを意味します。つまり、共有ポイントリストでSQLを使用できます(実際には、SharePointリストをこのように使用できるoleDBプロバイダーもありませんが、DAOを使用するとこれを実行できます)。 ADOに追加されたこの種のものはありません。したがって、アクセス(dao)の観点からのSharePointリストは、これらのSharePointリストを標準のテーブルと見なします。

さらに、アクセス中のDAOは、複雑なデータ型と呼ばれるものもサポートしています。これは、SharePointからのXMLリストをサポートするために行われました。次のバージョンのAccess(2010)では、DAO(JETは現在ACEと呼ばれています)にさらに多くの新しい追加機能が追加されることを覚えておいてください。

したがって、DAOが正しくて適切なモデルであることは間違いありません。 ADOはこれ以上拡張機能を受け取っておらず、ADO.NETに取って代わられています。

したがって、将来はDAOに属し、MicrosoftがMS Accessと、SharePointと連携するようにAccessをアップグレードするという観点から資金を投資しているのは明らかです。

Access 2007は、フィールド定義に対して複数値の機能を受け取りました。これも、SharePointをサポートするための機能強化の結果でした。ただし、これらの機能はJETの一部であり、これらの拡張機能はSharePointなしで使用できます。それらは現在DAOの一部です。


編集:おそらくこれを少し拡張して、ここでそのような反対の答えがあることを明確にしようと思います。Access2007を使用するときは、DAOを使用する方がはるかに良いと確信できます。

混乱が生じるのは、デフォルトのデータオブジェクトモデルアクセス2007を使用することを選択したときにツールの参照を見ると、ここでの問題は、DAOと呼ばれなくなったことです。現在はACEと呼ばれています。

Access 2007でDAOを使用する場合ツールリファレンスで、リファレンスがDAO 3.6に設定されていないことに注意してください(そのバージョンは減価償却されており、MDACダウンロードの一部ではなくなりました)。 ms-accessでDAOを使用する場合の新しい参照は、次のように呼び出されます。

Microsoft Office12.0Accessデータベースエンジンオブジェクトライブラリ

さて、上記は少し口いっぱいですが、ADOの代わりにDAOを使用する場合、上記はリファレンスアクセス2007に適しています。

言い換えれば、おそらくこれをDAOIIと呼ぶべきでしょう。

言い換えると、このデータエンジンは引き続き拡張されており、Office 2010(Office 14)用のこのエンジンの64ビットバージョンが確実に表示されます。

したがって、Access 2007でDAOを使用することについて言及するときに、どの用語が使用されるかという質問や混乱が中心になります。ここでの混乱は、実際には、ドキュメントやツール->リファレンスでさえDAOとは呼ばれていないことです。

Access 2007の1日の終わりに、DAOを使用する予定の場合は、上記の参照を設定し、DAO3.6への参照を設定しないことを意味します。とにかく、減価償却されたときにADOを使い始めるのはまったく意味がなく、アクセス用の新しいDAOオブジェクトモデルは引き続きMicrosoftによって強化され、投資されています。

これがここでの混乱を解消するのに役立つことを願っています。 DAO/JETは減価償却中ですが、新しいバージョンのAccess 2007は、引き続き拡張されていることを除いて、同じコードベースに基づいています。したがって、アクセス中の新しいデータエンジンを検討して、新しいDAOオブジェクトモデルと呼ぶことができます。

現在、この問題についてNDA)を行っていますが、Officeの次のバージョン(2010)では、多数の機能強化が再び行われることは間違いありません。

したがって、Accessアプリケーションを開発し、ネイティブデータエンジンを使用する場合、ここでの優先事項はDAOオブジェクトモデルを使用することです(ただし、これ以上はACEとは呼ばないことに注意してください)。

8

質問への答えはあなたが何をしているかによります。 Accessを使用して、ADOインターフェイスの方が用途が広い形式のデータを処理する場合は、ADOを使用します。Jetデータを使用する場合、またはJetデータベースエンジンを使用する場合は、別のデータベースエンジン(ODBC経由)を使用する場合は、DAOが正しい選択です。

しかし、その答えは、Accessから作業していることを前提としています。他のプログラミング環境で作業している場合、答えは完全に異なる可能性があります。

3
David-W-Fenton

それはあなたのニーズに依存します。どちらのツールもすぐになくなるとは思われません。

ADOまたはDAOのいずれかを使用した経験がない場合は、DAOの方がはるかに簡単であることがわかります。したがって、ADOが必要でない限り、DAOを使用してください。

この重要な項目を追加しました:「外部ソースからAccessDBにデータをプルしようとしています。」この接続にはADOが必要な場合があります。

2
Smandoli

ADOは、現在推奨されているアクセス方法です。 DAOはかなりの年数の間非推奨になっていると思います。

Access 2000以降のようです このリンク によると、

廃止されたデータアクセステクノロジのリスト- http://msdn.Microsoft.com/en-us/library/ms810810.aspx#mdac テクノロジロードマップold_topic9

2008年12月に改訂された上記の記事からの引用-「データアクセスオブジェクト(DAO):DAOはJET(アクセス)データベースへのアクセスを提供します。このAPIは、Microsoft Visual Basic、Microsoft Visual C++、およびスクリプト言語から使用できます。 Microsoft Office2000およびOfficeXPに含まれています。DAO3.6はこのテクノロジの最終バージョンです。64ビットのWindowsオペレーティングシステムでは使用できません。」

2
Scott Ivey

DAOは、ADOと比較してパフォーマンスの点で優れています。比較はありません。

1
Brandon

コメントであるはずだったのに、これが答えであるとお詫びします(私には担当者がいません)が、DAO/ACEDAOがJet4.0レコードロックをサポートしていないという誤った主張を明らかにしたいと思いました。特定のMS記事が何を主張しているかに関係なく、それはデフォルトの動作です。

問題は、DAO編集/更新を使用するときにこれが巨大な膨張(非常に断片化されたDBファイル)を引き起こす可能性があり、DAO/ACEDAOでそれをオフにできないことです。

この問題が発生した場合は、正しいJet OLEDB:データベースロックモード設定を使用して、OLEDB接続を介してデータベースを最初に開くことでオフにできます。これにより、データベースをページレベルのロックに設定できます。このプロパティは、結果として生じる接続、DAOなどによって尊重されるため、DAOを使用して高速更新などを行うことができます。

これにより、DAOはSQLステートメントの実行と比較して通常の8倍のパフォーマンスに戻ることができます。

この問題を指摘するリンクがいくつかあります。

ACEDAOは行レベルのロックをサポートしていますか?

http://www.access-programmers.co.uk/forums/showthread.php?t=4704

ADOでロックモードを設定し、そのDBでDAOを使用するコードを含むMS KBの記事- http://support.Microsoft.com/?id=306435

0
aristippus303