私の意見では、この質問は誠意を持って投稿されたものではありません。完全に私と、あなたのコメントに応えて私が行ったコメントに向けられたものです。私はすでに他の場所ですべての問題に答えていますが、物事を明確にするために、Jet の歴史の概要を説明させてください。
Jet は 90 年代初頭に Access とともに導入されました。バージョン 1 と 2 の間で、MS は Foxpro を買収し、その「Rushmore」テクノロジを Jet に組み込みました。この時期のどこかで、MS は Jet へのインターフェイス レイヤーとして DAO を開発しました。DAO が、すべてのデータ アクセスに Jet を使用するデータ インターフェイス レイヤー以外の何かとして存在していたという事実はわかりませんが、私にはそう見えました。Jet は、ODBC とインストール可能な ISAM を使用すると、ネイティブの Jet データと同じようにアプリで外観と動作を行うことができるため、Jet はかなり良い選択でした。当時、デスクトップ データベース市場は dBase とその亜種、および Paradox によって支配されていました。これらはすべてデスクトップ データベース エンジンであり、サーバー データベースではありません。サーバー データベースへのアクセスは、通常、ODBC を介して行われました。しかし、当時はデスクトップ db アプリケーション開発者にとってそれほど重要ではありませんでした。Jet は、ODBC データ ソースに接続し、それらを非常に効率的に利用することをかなりうまく管理していました。
現在、Access/Jet/DAO の台頭と並行して、Visual Basic は一般化された Windows アプリ開発のホットな製品であり、Web が繁栄する前は、VB は世界で最も広く使用されているプログラミング言語でした。DAO と Jet は、あらゆる種類のデータ ストアへのインターフェイスを VB 開発者に提供し、VB 開発ツールはそれらとうまく統合されていました。このように、ODBC の後、DAO は MS の重要なデータ インターフェイス レイヤーとなり、Jet エンジンを利用してあらゆる種類のデータを操作しました。
当然のことながら、これには問題があり、Jet/DAO (および VB) はすべてデスクトップ指向のツールであるという点で非常に制限的でした。90 年代半ばから後半にかけて、MS はデスクトップ ソフトウェア、デスクトップ OS、および開発ツールのプロバイダーからエンタープライズ ソフトウェア プロバイダーへの拡大を試みていました。そのため、MS は、データベース サーバー用の ODBC のような、より堅牢なデータ インターフェイスを開発する必要がありましたが、新しいサーバー データベースが提供する最新の機能をすべて備えていました。OLEDB は、OLEDB 上のインターフェイス レイヤーとして ADO を使用することで、これに対する答えでした (DAO が Jet 上のインターフェイス レイヤーであるように)。DAO の目標は Jet データベース エンジンを介して多くのデータ ストアへのアクセスを提供することでしたが、OLEDB は ODBC のようなより中立的なデータ インターフェイス レイヤーであり、データベース抽象化レイヤーであり、ADO はその中立的なデータ インターフェイス レイヤーへのインターフェイスでした。
「ネイティブ」DDL の問題について言えば、Jet 4 より前は SQL DDL のサポートが非常に貧弱であったことは事実です。つまり、SQL DDL では制御できない Jet の機能がありました。代わりに、DAO を使用してこれらの機能を制御する必要がありました。Jet Database Engine Programmer's には、DAO の例と一緒に DDL の例が含まれていますが、Jet DDL SQL は Jet データベースのすべての機能をサポートしていないため、DAO の例ではさらに多くのことができます。
非常に紛らわしいと思われる内訳は、MS の内部政治が原因で発生しました。MS が Access 2000 (新しいバージョンの Jet 4.0 を含む) を導入した 1999 年までに、MS は ADO を優先して DAO を廃止したいと考えました。MS は、ADO を使用する意味がない (つまり、データ ストアが Jet である) 場合でも、ADO を Access の既定のデータ インターフェイス レイヤーにしました。この取り組みの一環として、MS は DAO を完全に更新して Jet 4 のすべての新機能のサポートを組み込むことはしませんでした。代わりに、MS はこの面での努力を ADO に注ぎ込みました。その結果、Jet のネイティブ データ インターフェイス レイヤーである DAO は、データベースに依存しないインターフェイス レイヤーである ADO が提供する Jet 機能をサポートしていませんでした。私の意見では、これは Microsoft 側の特殊な形のダッチバッガリーでした。MS は意図的に Jet を更新していませんでした。非ネイティブ インターフェイスの使用を強制するためのネイティブ インターフェイス レイヤー。そのため、DAO->Jet の代わりに、ADO->OLEDB->Jet を使用する必要があり、Jet データベース エンジンのネイティブな側面 (フィールドのデータ型など) についてもそうでした。
Microsoft の目標は、DAO を完全に殺すことであり、実際には Jet 自体を殺すことでした。彼らは、顧客が SQL Server に移行することを望んでいました。
しかし、多くのことが起こりました。1 つには、COM ベースの ADO は .NET とうまく適合できなかったため、従来の COM ベースの ADO は最終的に放棄され、代わりに ADO.NET が作成されました。ADO と ADO.NET の類似点は非常に表面的なものであり、データ相互作用の完全に異なるモデルに基づいています。ADO.NET は、切断されたデータのアイデアに基づいてほぼ完全に設計されていますが、ADO はそうではありませんでした (ただし、特定の種類の切断されたデータは確かにサポートされていました)。データアクセス）。
ADO の廃止により、MS の製品ラインには穴が開いていました。従来の VB 開発者や Access 開発者は、データ アクセス モデル全体が適合しなかったため、.NET に大きなメリットを感じることはありませんでした。したがって、Access 2002 のリリースまでに、MS はコースを逆にして、DAO を Jet データのデフォルトのデータ インターフェイス層として元の場所に戻しました (そして、Jet が ODBC などを介して操作できる他のすべてのデータ ストア)。残念なことに、MS は現在 Jet で使用する ADO を非推奨にしていますが、Jet に付属していた障害のあるバージョンの DAO を修正することを選択しませんでした。この時点で、既存の Jet 4 を Access 開発グループが所有するデータベース エンジンにフォークするという決定が下されたため、おそらく彼らはこれを実行しませんでした。これは最終的に ACE になり、すべての意図と目的において Jet 4.5 です。DAO の新しいバージョンがリリースされました (DLL 名は現在 ACEDAO.DLL ですが、ユーザー フレンドリな名前は "Microsoft Office 12.0 Access データベース エンジン オブジェクト ライブラリ" で、少し偽装されています)。DAO 3.6 (Jet 4 バージョン) に欠けていた機能が、DAO の ACE バージョンにどの程度追加されたかはわかりません。ないからわからないこれらの機能のいずれかが必要なので、それらが何であるかさえ知りません。
いずれにせよ、現時点では、Jet (Jet 4 で終わりだと約束されていた) と、Jet ネイティブのデータ インターフェイス層 (DAO も終了すると約束されていた) の開発が進行中です。 . この進行中の開発は、Microsoft の Access アプリケーション グループ内で行われています (以前は Jet 4 が維持されていた Windows とは対照的です)。
Microsoft は Access に互換モードを追加し、ANSI-92 SQL モードと呼ばれるものを使用しました。これにより、SQL Server の SQL ダイアレクトと「互換性がある」SQL を記述できるようになります。まあ、それはいくつかのことをサポートします (SQL Server のワイルドカードを使用し、Jet の厄介な [] の代わりに () を派生テーブルに使用できます。エイリアスとして)、TSQL にあまり近くありません。しかし、Access 以外では、この "ANSI-92" SQL モードを使用する唯一の方法は、ADO を使用して Jet に接続することです。DAO 自体は、まだ Jet の SQL の古い方言を使用しています。これは、Jet がこのモード自体のサポートを提供していないことを示していますが、Jet の上のレイヤーによって提供されています。