ODBCにまつわるトラブル集
Updated 1997/11/03
By 富士通ＳＳＬ）福岡寿和
私がWindowsパソコン上での開発で感じているのは、「未調査による仕様の誤解」と「ソフト／ハードの相性」が原因のトラブルが多いということです。この原因によるトラブルで、特に近頃私の周りで多いのが、Visual BasicからOracleを使うときのトラブルです。そして、はまってしまったときの原因は、必ずと言っていいほど、ODBCという規約を誤解していることから生じています。
TIPS1:ODBCはRDBMSの機能差を解消するものではない
ODBCは、あくまでもSQL文を発行したり、カーソルを制御して情報を入出力する手段を共通化するものです。このODBCの機能を拡大解釈してしまい、ODBCを使ってやり取りするSQL文の文法やストアードプロシージャの機能差なども共通化できると勘違いしてしまうことがあるようです。確かに、SQL文はSQL3などの共通規格もあることはありますが、きちんとRDBMSの機能を使おうと思えば思うほど、共通規格からの差異に苦しめられます。そして、業務アプリケーションを作るときには、この差異の部分まで踏み込んでSQL文を使う必要があります。更に、LAN負荷を考えたり、従量課金制WAN回線を使うときには、ストアードプロシージャを使うこともあります。このストアードプロシージャは、RDBMSごとに完全に別物であることも忘れられがちです。ですから、ODBCデータソースの設定を切り替えるだけで、OracleとSQL Serverのどちらでも動作する「レスポンスのよい」アプリケーションをつくるのは不可能でしょう。
TIPS2:DAOはローカルデータ用である
DAO/JetによりAccessと接続しているプログラムをODBC経由に切り替えるだけで、簡単にSQL ServerやOracle用に変更できるとの誤った認識があります。
DAO/Jetは、SQLパススルーを指定しないでODBCデータソースに接続すると、SQL文をすべてDAO/Jetが解釈してODBCデータソースに渡します。一見この方法は有用なように思えますが、DAO/Jetの解釈後のSQL文が必ずしもすべてのRDBMSにとって最適な解ではありませんし、DA/JetとRDBMSの２個所でSQL文の解釈をするので、処理効率も決して高い方ではありません。また、場合によっては更新可能なレコードセットを作れないなどの機能制限もあります。せめて、検索系（例えば、印刷をするなど）以外にはDAO/Jet経由でRDBMSと接続しないなのどの自衛策が必要でしょう。Visual BasicにはRDOがあるのですから、DAO/Jetなど使わずにRDOを使うのが本筋と言えるでしょう。
TIPS3:ODBCには様々なレベルがある
ODBCドライバがどのODBCレベルをサポートしているか不明確なときが多く、特にOracleではその傾向が強い気がします。
ODBCレベルとそのレベルで使用できるアクセス方法は、だいたい
| ＯＤＢＣレベル１ | DAO/Jet |
| ＯＤＢＣレベル２ | RDO1.0 |
| ＯＤＢＣレベル３ | OFFICE97やVisual Studio97のODBCドライバマネージャ3.0（結果的にODBC DirectとRDO2.0も）
|
のようになっています。
ここで問題になってくるのは、OFFICE97やVisualStudio97から導入されたODBCドライバマネージャ3.0です。
このODBCドライバマネージャが導入されるとそれまでに出荷・提供されていたOracle用のODBCドライバの動作が不安定になります。
Visual Basic 5.0にもMicrosoft ODBC Driver for Oracle 2.0ということで対応版が提供されています。
しかし、このODBCドライバもODBCレベル３をフルサポートしていないようです。このように「ODBCで繋がる」といっても様々な技術要素が絡んできます。
TIPS4:RDBMSのネットワークライブラリとの相性
ODBCドライバのバージョンを変更したときには更に注意が必要です。それは、RDBMSのネットワークライブラリ、例えば、SQL Serverならば、Net-Library、OracleならばSQL*Netのバージョンが対応しているかという点です。現に、Microsoft ODBC Driver for Oracle 2.0やOracle社のODBC Driver 2.0は、SQL*Net 2.3が必要です。これは、単にSQL*Net 2.2以前の動作確認を時間と費用の面から行っていないだけかもしれません。しかし、どのメソッドがODBCレベル３に変更した影響を受けているか公開されていない現状では、今まで動作していた部分が動かなくなったという事例も聞きますので、SQL*Net 2.3の導入を検討した方がよいと思います。もちろん、ODBCドライバのバージョンを変更しないという手段もありますが、ODBCドライバマネージャ3.0が導入されてしまったときには、ODBCドライバのバージョンを変えるしかありません。
結論としては、SQL ServerとであればODBCの構成の煩雑さも余り影響がないので、ODBCを使うことが業務アプリケーション作成の要求事項にあるのならば、RDBMSをSQL Serverに限定したほうがよく、もし、Oracleをつかうことが要求事項にあるならば、ODBCは検索系に限定したほうがよいでしょう。この２つの要求事項を同時に満足させることは現時点では、不可能に近いくらいリスキーなことです。ODBCの仕様が安定してくれるか、日本人が気長になって少しくらい更新系が遅くても気にならなくなるかのどちらかしか根本的な解決は図れないでしょう。
Visual Basic
開発者の手引き | Visual
Basicコースホームページ
int21 ホームページ | PCDN ホームページ
