オープンデータベース接続

コンピューティングにおいて、Open Database Connectivity ( ODBC ) は、データベース管理システム(DBMS)にアクセスするための標準アプリケーション プログラミング インターフェイス(API) です。ODBC の設計者は、ODBC をデータベース システムやオペレーティング システムから独立させることを目指しました。^[要出典] ODBC を使用して作成されたアプリケーションは、データ アクセス コードをほとんど変更せずに、クライアント側とサーバー側の両方で他のプラットフォームに 移植できます。

ODBC は、 ODBCドライバーをアプリケーションと DBMS 間の変換レイヤーとして使用することで、DBMS の独立性を実現します。アプリケーションは、リンクされているODBC ドライバー マネージャーを介して ODBC 関数を使用し、ドライバーはクエリをDBMS に渡します。ODBC ドライバーは、プリンター ドライバーやその他のドライバーに類似したものと考えることができます。アプリケーションが使用する関数の標準セットを提供し、DBMS 固有の機能を実装します。ODBC を使用できるアプリケーションは、「ODBC 準拠」と呼ばれます。ODBC 準拠のアプリケーションは、ドライバーがインストールされているすべての DBMS にアクセスできます。すべての主要な DBMS、アドレス帳システムやMicrosoft Excelなどの他の多くのデータ ソース、さらにはテキスト ファイルやコンマ区切り値(CSV) ファイル用のドライバーが存在します。

ODBC は、もともと1990 年代初期にMicrosoftとSimba Technologiesによって開発され、 Unixおよびメインフレーム分野でSQL Access Groupによって標準化されたコール レベル インターフェイス(CLI)の基盤となりました。ODBC には、CLI の取り組みの一環として削除されたいくつかの機能が保持されていました。その後、完全な ODBC がそれらのプラットフォームに移植され、 CLI よりもかなりよく知られる事実上の標準となりました。CLI は ODBC と似ており、アプリケーションはわずかな変更を加えるだけで、あるプラットフォームから別のプラットフォームに移植できます。

1970 年代にメインフレームベースのリレーショナル データベースが導入されたことで、データ アクセス方法が急増しました。通常、これらのシステムは、ユーザーが英語のようなコマンドを入力して出力を受け取ることができるシンプルなコマンド プロセッサとともに動作しました。最もよく知られている例は、 IBMのSQLとIngresプロジェクトのQUELです。これらのシステムでは、他のアプリケーションがデータに直接アクセスできる場合とできない場合があります。また、アクセスする場合はさまざまな方法を使用します。SQLの導入は、言語の標準化の問題を解決することを目的としていましたが、実装には大きな違いが残りました。

SQL 言語には基本的なプログラミング機能しかなかったため、ユーザーはFortranやCなどの別の言語で書かれたプログラム内で SQL を使用したいと考えることがよくありました。これが埋め込み SQLの概念につながり、SQLコードを別の言語内に埋め込むことができるようになりました。たとえば、次のような SQL ステートメントSELECT * FROM cityを C ソース コード内にテキストとして挿入すると、コンパイル中にカスタム形式に変換され、ライブラリ内の関数が直接呼び出されてステートメントが SQL システムに渡されます。ステートメントから返された結果は、char *同様のライブラリ コードを使用して、 次のような C データ形式に解釈されます。

埋め込み SQL のアプローチには、いくつかの問題がありました。SQL のさまざまな種類と同様に、それらを使用する埋め込み SQL も、プラットフォーム間だけでなく、1 つのプラットフォーム上の言語間でも大きく異なっていました。つまり、IBM Db2への呼び出しを許可するシステムは、独自のSQL/DSへの呼び出しを許可するシステムとは非常に異なって見えるでしょう。^{[疑わしい–議論する]}埋め込み SQL の概念のもう 1 つの重要な問題は、SQL コードを変更できるのはプログラムのソース コード内でのみであるため、クエリに小さな変更を加えるだけでも、プログラマーが修正するためにかなりの労力が必要になることでした。SQL 市場では、これを静的 SQLと呼び、ほぼすべてのSQLシステムに付属しているコマンド ライン インターフェイスや、呼び出されるまで SQL をプレーン テキストのままにするプログラミング インターフェイスのように、いつでも変更できる動的 SQL と対比しました。動的 SQL システムは、1980 年代に SQL ベンダーの主要な焦点となりました。

旧式のメインフレーム データベース、およびそれをベースにした新しいマイクロコンピュータベースのシステムでは、通常、ユーザーとデータベース エンジンの間に SQL のようなコマンド プロセッサがありませんでした。代わりに、データはプログラムによって直接アクセスされました。大規模なメインフレーム システムの場合はプログラミング ライブラリ、dBASEや同様のアプリケーションの場合はコマンド ライン インターフェイスまたは対話型フォーム システムです。通常、dBASE のデータは、マシンで実行されている他のプログラムによって直接アクセスすることはできません。これらのプログラムには、多くの場合ライブラリを介してこのデータにアクセスする方法が提供されますが、他のデータベース エンジンや、同じエンジン内の異なるデータベースでは機能しません。実際、このようなシステムはすべて静的であり、かなりの問題が発生しました。

1980 年代半ばまでに、マイクロコンピュータの急速な進歩、特にグラフィカル ユーザー インターフェイスとLotus 1-2-3のようなデータ豊富なアプリケーション プログラムの導入により、クライアント サーバーコンピューティングにおけるクライアント側プラットフォームとしてパーソナル コンピュータを使用することへの関心が高まりました。このモデルでは、大型のメインフレームとミニコンピュータは主に、ローカル エリア ネットワーク経由でマイクロコンピュータにデータを提供し、マイクロコンピュータがそのデータを解釈、表示、操作するために使用されます。このモデルが機能するには、データ アクセス標準が必要でした。メインフレームの分野では、ショップ内のすべてのコンピュータが 1 つのベンダー製であり、クライアントがそれらのコンピュータと直接通信するコンピュータ端末である可能性が非常に高かったのですが、マイクロの分野ではそのような標準化はなく、どのクライアントも任意のネットワーク システムを使用して任意のサーバーにアクセスできます。

1980 年代後半までに、この目的のために抽象化レイヤーを提供する取り組みがいくつか進行していました。これらの一部はメインフレーム関連で、それらのマシンで実行されるプログラムがさまざまな SQL を変換し、他のメインフレームまたはマイクロコンピュータ プログラムから呼び出すことができる単一の共通インターフェイスを提供できるように設計されていました。これらのソリューションには、IBM の分散リレーショナル データベース アーキテクチャ ( DRDA ) やApple Computerのデータ アクセス言語が含まれていました。ただし、より一般的だったのは、必要なネットワークやファイル変換サポートを含む完全なプロトコル スタックを含む、完全にマイクロコンピュータで実行されるシステムでした。

こうしたシステムの初期の例の 1 つに 、当初 Blueprint と呼ばれていたLotus DevelopmentのDataLensがあります。1-2-3 向けに開発された Blueprint は、SQL/DS、DB2、 FOCUS 、さまざまな同様のメインフレーム システム、 dBaseなどのマイクロコンピュータ システム、最終的にMicrosoft SQL Serverに発展する初期の Microsoft/Ashton-Tate の取り組みなど、さまざまなデータ ソースをサポートしていました。^[1]後の ODBC とは異なり、Blueprint は完全にコード ベースのシステムであり、SQL のようなコマンド言語に近いものは何もありませんでした。代わりに、プログラマーはデータ構造を使用してクエリ情報を格納し、これらの構造の多くをリンクすることでクエリを構築しました。Lotus はこれらの複合構造をクエリ ツリーと呼んでいました。^[2]

同じ頃、Sybase (Tom Haggin)、Tandem Computers ( Jim Grayと Rao Yendluri)、Microsoft (Kyle Geiger) のメンバーを含む業界チームが、標準化された動的 SQL の概念に取り組んでいました。システムの大部分は Sybase の DB-Library システムに基づいており、Sybase 固有のセクションが削除され、他のプラットフォームをサポートするためにいくつかの追加が行われていました。^{[3] DB-Library は、特定の言語に密接にリンクされたライブラリ システムから、}オペレーティング システムによって提供され、そのプラットフォーム上の言語がその標準に準拠することを要求するライブラリ システムへの業界全体の移行によって促進されました。これは、単一のライブラリが、特定のプラットフォーム上の (潜在的に) どのプログラミング言語でも使用できることを意味しました。

Microsoft Data Access APIの最初のドラフトは、Lotus が Blueprint を発表したのとほぼ同時期の 1989 年 4 月に公開されました。^[4] Blueprint は MSDA がまだ紙のプロジェクトだったときに大きくリードしていましたが、SQL が事実上のデータベース標準になることが明らかになったため、Lotus は最終的に MSDA の取り組みに参加しました。^[2]業界からの多大な意見を受けて、1989 年の夏に標準はSQL Connectivity ( SQLC ) になりました。^[5]

1988年、主にUnixおよびデータベースコミュニティの複数のベンダーが、SQL言語の単一の基本標準を作成するためにSQLアクセスグループ（SAG）を結成しました。最初の会議では、SQL言語自体のみに取り組むべきか、または動的なSQL言語埋め込みシステム（彼らがコールレベルインターフェイス（CLI）と呼ぶもの）も含めたより広範な標準化を試みるべきかどうかについてかなりの議論がありました。^[6]当時まだMS Data Accessとして知られていたものの初期ドラフトを持って会議に出席していたMicrosoftのKyle Geigerは、Digital Equipment Corporation（DEC）のJeff BalboniとLarry BarnesにもSQLC会議に参加するよう招待しました。SQLCは、DECが主導していたCLIの要求に対する潜在的な解決策でした。

新しい SQLC「4 人組」、MS、Tandem、DEC、Sybase は、1990 年 6 月の次の SAG 会議に SQLC の更新バージョンを持ち込みました。^[7] SAG は、競合する設計に対して標準の取り組みを開放することで対応しましたが、多くの提案の中で、真剣に競合するシステムを持っていたのはOracle Corpだけでした。最終的に、SQLC が投票で勝利し、ドラフト標準になりましたが、それは API の大部分が削除された後のことでした。この間に、標準ドキュメントは 120 ページから 50 ページに削減されました。また、この時期に、Call Level Interface という名前が正式に採用されました。^[7] 1995 年、SQL/CLI は国際 SQL 標準である ISO/IEC 9075-3 の一部になりました。^{[8] SAG 自体は 1996 年に}X/Openグループに引き継がれ、やがてThe Open GroupのCommon Application Environmentの一部になりました。

MS はオリジナルの SQLC 標準を引き続き使用し、CLI バージョンから削除された高度な機能の多くを維持しました。これには、スクロール可能なカーソルやメタデータ情報クエリなどの機能が含まれます。API のコマンドはグループに分割されました。コア グループは CLI と同一で、レベル 1 拡張はドライバーに簡単に実装できるコマンドであり、レベル 2 コマンドにはカーソルなどのより高度な機能が含まれていました。提案された標準は 1991 年 12 月にリリースされ、業界からの意見が集められて 1992 年を通じてシステムに取り込まれ、ODBCへの名前変更が再び行われました。^[9]

この頃、Microsoft はJet データベース システムの開発の真っ最中でした。Jet は、ISAMベースのデータベース エンジン (紛らわしいことにJetとも​​呼ばれています)、アプリケーションがそのデータにアクセスできるようにする C ベースのインターフェイス、および同じ C インターフェイスで入出力をParadoxやxBaseなどの他の ISAM ベースのデータベースにリダイレクトできるようにする一連のドライバーダイナミック リンク ライブラリ(DLL) という 3 つの主要なサブシステムを統合していました。Jet では、Blueprint (当時 DataLens と改名) と同様の方法で、1 セットの呼び出しを使用して一般的なマイクロコンピューター データベースにアクセスできました。ただし、Jet は SQL を使用しませんでした。DataLens と同様に、インターフェイスは C で、データ構造と関数呼び出しで構成されていました。

SAG の標準化活動は、Microsoft に Jet システムを新しい CLI 標準に適合させる機会を与えました。これにより、Windows は CLI 開発の最高のプラットフォームになるだけでなく、ユーザーは SQL を使用して Jet と他のデータベースの両方にアクセスできるようになります。不足していたのは、それらの呼び出しをテキスト形式から Jet で使用される C インターフェイスに変換できる SQL パーサーでした。これを解決するために、Microsoft はPageAhead Softwareと提携して、既存のクエリ プロセッサである SIMBA を使用しました。SIMBA は Jet の C ライブラリ上のパーサーとして使用され、Jet を SQL データベースに変換しました。また、Jet はそれらの C ベースの呼び出しを他のデータベースに転送できるため、SIMBA は他のシステムに対してもクエリを実行できました。Microsoft は Excel 用のドライバーを組み込み、スプレッドシート ドキュメントを SQL でアクセス可能なデータベース テーブルに変換しました。^[10]

ODBC 1.0 は 1992 年 9 月にリリースされました。^[11]当時は、SQL データベース (ISAM と比較して) を直接サポートするものはほとんどなく、初期のドライバーはパフォーマンスが低いことで知られていました。これは、呼び出しが Jet ベースのスタックを通過するパスが原因で避けられないことがありました。SQL データベースへの ODBC 呼び出しは、まずSimba Technologiesの SQL 方言から Jet の内部 C ベース形式に変換され、次にドライバーに渡されてデータベースの SQL 呼び出しに変換されました。Digital EquipmentとOracle はどちらも、自社のデータベース用のドライバーの開発もSimba Technologiesに委託しました。^[12]

1993年頃、OpenLink SoftwareはPROGRESS DBMS用の独自開発された最初のサードパーティODBCドライバの1つを出荷しました^[13]。その後すぐにUDBC（ODBCとSAG/CLIに相当するクロスプラットフォームAPI）SDKとPROGRESS 、Sybase、Oracle、その他のDBMS用の関連ドライバを出荷し、Unix系OS（ AIX、HP-UX、Solaris、Linuxなど）、VMS、Windows NT、OS/2、その他のOSで使用しました^{[14] 。}

一方、CLI 標準化の取り組みは長引き、最終版が完成したのは 1995 年 3 月になってからでした。その時点で、Microsoft は既に Visigenic Software に、Windows 以外のプラットフォームで ODBC を開発するためのソース コードライセンスを付与していました。Visigenic は ODBC をクラシック Mac OSやさまざまな Unix プラットフォームに移植し、ODBC はすぐに事実上の標準となりました。^[15]「本物の」CLI は今日では珍しいものです。2 つのシステムは類似したままであり、多くのアプリケーションは ODBC から CLI にほとんどまたはまったく変更せずに移植できます。^[16]

時間が経つにつれて、データベースベンダーがドライバーインターフェイスを引き継ぎ、自社製品への直接リンクを提供するようになりました。Jet や類似のラッパーとの中間変換を省略すると、多くの場合、パフォーマンスが向上しました。しかし、その頃には Microsoft はOLE DB ^[17]コンセプト (最近復活^{[18] ) に焦点を移しており、}アドレス帳からテキストファイルまで、より幅広いデータソースに直接アクセスできるようになりました。その後、 ActiveX Data Objects (ADO) やADO.netなど、ODBC からさらに注意をそらす新しいシステムがいくつか登場しました。これらのシステムは、その存続期間中、多かれ少なかれ ODBC とやり取りしていました。

Microsoft が ODBC への直接的な取り組みから関心をそらすにつれて、Unix 分野では ODBC がますます採用されるようになりました。これは、市場における 2 つの変化によって推進されました。1つは、 GNOMEなどのグラフィカル ユーザー インターフェイス(GUI)の導入によって、これらのソースに非テキスト形式でアクセスする必要が生じたこと、もう 1 つは、当初 Unix で登場したPostgreSQLやMySQLなどのオープン ソフトウェアデータベース システムです。後に Apple が ODBC を採用し、標準の Unix 側iODBCパッケージMac OS X 10.2 (Jaguar) ^[19] (OpenLink Software は 2001 年から Mac OS X 10.0 および Mac OS 9 向けに独自に提供していました^[20] ) を使用するようになりました。

Sun Microsystems は、 ODBC システムを自社のオープン スタンダードであるJava Database Connectivity (JDBC)の基盤として使用しました。ほとんどの点で、JDBC はCではなくプログラミング言語Java用の ODBC バージョンと考えることができます。JDBC から ODBC へのブリッジにより、Java ベースのプログラムはネイティブ JDBC ドライバーがないプラットフォーム上の ODBC ドライバーを介してデータ ソースにアクセスできますが、このようなプラットフォームは現在では比較的まれです。逆に、ODBC から JDBC へのブリッジにより、C ベースのプログラムは適切な ODBC ドライバーがないプラットフォーム上またはデータベース上の JDBC ドライバーを介してデータ ソースにアクセスできます。

ODBCは現在でも広く使用されており、ほとんどのプラットフォームとほとんどのデータベースでドライバーが利用可能です。SQLiteのような埋め込み型データベースエンジン用のODBCドライバーは珍しくなく、既存のツールをこれらのエンジンのフロントエンドとして機能させてテストやデバッグを行う手段として使用されています。^[21]

• 1.0: 1992年9月にリリース^[23]
• 2.0: 1994年頃
• 2.5
• 3.0: 1995年頃、インターソルブのジョン・グッドソンとIBMのフランク・ペローとポール・コットンがODBC 3.0に重要な貢献をした^[24]
• 3.5: 1997年頃
• 3.8: 2009年頃、Windows 7搭載^[25]
• 4.0: 2016年6月に開発が発表され^[26]、2017年9月にSQL Server 2017での最初の実装がリリースされ、2018年後半にデスクトップドライバが追加され、最終仕様がGithubに掲載された。

• 1.0 (1993–08): PageAhead Software が作成した SIMBA クエリ プロセッサを使用しました。
• 2.0 (1994–12): ODBC 2.0 で使用されます。
• 3.0 (1995–10): Windows 95 および Windows NT Workstation または NT Server 3.51 をサポートします。このリリースには 32 ビット ドライバーのみが含まれていました。
• 3.5 (1996 ～ 1910): 2 バイト文字セット (DBCS) をサポートし、ファイル データ ソース名 (DSN) の使用に対応しました。Microsoft Access ドライバは、Windows 95/98 および Windows NT 3.51 以降のオペレーティング システムの Alpha プラットフォームで使用するために RISC バージョンでリリースされました。
• 4.0 (1998 年後半): 以前のバージョンの ANSI 形式との互換性とともに、Microsoft Jet Engine Unicode 形式をサポートします。

ODBC はデバイス ドライバーモデルに基づいており、ドライバーは、コマンドと関数の標準セットを、基盤となるシステムで必要な特定の呼び出しに変換するために必要なロジックをカプセル化します。たとえば、プリンター ドライバーは、印刷システムを使用するアプリケーションに、印刷コマンドの標準セットである API を提供します。これらの API への呼び出しは、ドライバーによって、実際のハードウェアで使用される形式 ( PostScriptやPCLなど) に変換されます。

ODBC の場合、ドライバーは多くの関数をカプセル化しますが、これらはいくつかの幅広いカテゴリに分類できます。関数の 1 つのセットは、主にドライバーが通信する DBMS の検索、接続、および切断に関係します。2 番目のセットは、ODBC システムから DBMS に SQL コマンドを送信し、内部でサポートされていないコマンドを変換または解釈するために使用されます。たとえば、カーソルをサポートしていない DBMSは、ドライバーでこの機能をエミュレートできます。最後に、主に内部で使用される別のコマンド セットは、DBMS の内部形式から C 言語形式に基づく一連の標準化された ODBC 形式にデータを変換するために使用されます。

ODBC ドライバーにより、ODBC 準拠のアプリケーションはデータ ソース(通常は DBMS) を使用できるようになります。CSV ファイルなどのデータ ソース用に、ドライバー自体の中に小さな DBMS を実装した非 DBMS ドライバーも存在します。ODBCドライバーは、 Oracle、PostgreSQL、MySQL、Microsoft SQL Server ( Compact 別名 CE エディション用はありません)、Mimer SQL、Sybase ASE、SAP HANA ^{[28] [29]}、IBM Db2など、ほとんどの DBMS 用に存在します。テクノロジが異なれば機能も異なるため、ほとんどの ODBC ドライバーは ODBC 標準で定義されているすべての機能を実装しているわけではありません。一部のドライバーは、標準で定義されていない追加機能を提供します。

デバイス ドライバーは通常、別のマネージャー レイヤーによって列挙、セットアップ、管理され、追加の機能が提供される場合があります。たとえば、印刷システムには、ドライバーの上に スプール機能を提供する機能が含まれていることが多く、サポートされているすべてのプリンターに印刷スプールを提供します。

ODBCでは、ドライバーマネージャー（DM）がこれらの機能を提供します。^[30] DMはインストールされているドライバーを列挙し、多くの場合GUIベースの形式でリストとして表示できます。

しかし、ODBC システムの操作にとってより重要なのは、DM のデータ ソース名(DSN) の概念です。DSN は、DBMS 自体ではなく、特定のデータ ソースに接続するために必要な追加情報を収集します。たとえば、同じMySQLドライバーを使用して任意の MySQL サーバーに接続できますが、ローカルのプライベート サーバーに接続するための接続情報は、インターネットでホストされているパブリック サーバーに接続するために必要な情報とは異なります。DSN はこの情報を標準化された形式で保存し、DM は接続要求時にドライバーにこれを提供します。DM には、人間が判読できる名前を使用して DSN のリストを表示し、実行時にそれらを選択してさまざまなリソースに接続する機能も含まれています。

DM には、部分的に完了した DSN を保存する機能も含まれており、実行時に不足している情報をユーザーに尋ねるコードとロジックが含まれています。たとえば、必要なパスワードなしで DSN を作成できます。ODBC アプリケーションがこの DSN を使用して DBMS に接続しようとすると、システムは一時停止し、続行する前にユーザーにパスワードの入力を求めます。これにより、アプリケーション開発者は、この種のコードを作成する必要がなくなり、どのような質問をすればよいかを知る必要もありません。これらすべてがドライバーと DSN に含まれています。

ブリッジは特別な種類のドライバーであり、別のドライバーベースのテクノロジを使用するドライバーです。

ODBC-JDBC ブリッジは、データベースに接続するためにJDBC ドライバーのサービスを使用するODBCドライバーで構成されます。このドライバーは、ODBC 関数呼び出しを JDBC メソッド呼び出しに変換します。プログラマーは通常、データベース用の ODBC ドライバーがないが、JDBC ドライバーにアクセスできる場合にこのようなブリッジを使用します。例: OpenLink ODBC-JDBC ブリッジ、SequeLink ODBC-JDBC ブリッジ。

JDBC-ODBC ブリッジは、ODBC ドライバーを使用してターゲット データベースに接続する JDBCドライバーで構成されます。このドライバーは、JDBCメソッド呼び出しを ODBC 関数呼び出しに変換します。プログラマーがこのようなブリッジを使用するのは、通常、特定のデータベースに JDBC ドライバーが存在しないが、ODBC ドライバーを介してアクセスできる場合です。Sun Microsystems は、 JVMにこのようなブリッジを 1 つ組み込みましたが、これは、JDBC ドライバーがほとんど存在しない間の一時的な手段とみなされていました (組み込みの JDBC-ODBC ブリッジは、Java 8 で JVM から削除されました^[31] )。Sun は、このブリッジを実稼働環境で使用することを意図したことはなく、一般的に使用を推奨していません。2008 年現在、^{[アップデート]}独立したデータ アクセス ベンダーが、両方のメカニズムの現在の標準をサポートし、JVM 組み込みよりもはるかに優れたパフォーマンスを発揮する JDBC-ODBC ブリッジを提供しています。^{[出典が必要]}例: OpenLink JDBC-ODBC ブリッジ、SequeLink JDBC-ODBC ブリッジ、ZappySys JDBC-ODBC ブリッジ。

OLE DB-ODBC ブリッジは、ODBC ドライバーのサービスを使用してターゲット データベースに接続するOLE DBプロバイダーで構成されます。このプロバイダーは、OLE DBメソッド呼び出しを ODBC 関数呼び出しに変換します。プログラマーは通常、特定のデータベースに OLE DB プロバイダーがなく、ODBC ドライバーを介してアクセスできる場合に、このようなブリッジを使用します。Microsoft は、COM 対応言語 ( Visual Basicなど) での開発を簡素化するために、他のデータベース ドライバーとともに、 MDACシステム コンポーネント バンドルの一部として MSDASQL.DLL を出荷しています。サード パーティもこのようなブリッジを開発しており、特に OpenLink Software は、Microsoft が当初 64 ビット OS でこのブリッジを非推奨にしたときに、ODBC データ ソース用の 64 ビット OLE DB プロバイダーでそのギャップを埋めました。^{[32] (Microsoft は後に態度を軟化させ、} Windows Server 2008およびWindows Vista SP1 以降の 64 ビット Windows には、64 ビット バージョンの MSDASQL が同梱されています。) 例: OpenLink OLEDB-ODBC ブリッジ、SequeLink OLEDB-ODBC ブリッジ。

ADO.NET-ODBC ブリッジは、ODBC ドライバーのサービスを使用してターゲット データベースに接続するADO.NET プロバイダーで構成されます。このプロバイダーは、ADO.NETメソッド呼び出しを ODBC 関数呼び出しに変換します。プログラマーは通常、特定のデータベースに ADO.NET プロバイダーがなく、ODBC ドライバーを介してアクセスできる場合に、このようなブリッジを使用します。Microsoft は、C#での開発を簡素化するために、他のデータベース ドライバーとともに、MDACシステム コンポーネント バンドルの一部としてブリッジを出荷しています。サード パーティもこのようなブリッジを開発しています。例: OpenLink ADO.NET-ODBC ブリッジ、SequeLink ADO.NET-ODBC ブリッジ。

• GNU データ アクセス
• Java データベース接続(JDBC)
• Windows オープン サービス アーキテクチャ
• ODBC 管理者

文献

引用

• Microsoft ODBC の概要
• IBM i ODBC 管理
• www.roth.net からのプレゼンテーション スライド
• Microsoft ODBC およびデータ アクセス API の履歴に関する記事。
• Github ページ: Microsoft ODBC 4.0 仕様