Visual Basic 5.0の登場

　決定的な解決策がないまま時間が経過し，Visual Basic 5.0のテクニカルインフォメーションが公開された．注目したのはActiveX Documentsである．ActiveXコントロールが動的にダウンロードされるプログラミングオブジエクトだとすると，ActiveX Documentsは動的にブラウザ内にダウンロードされるプログラムである．このプログラムはVisual Basicプログラムとほぼ同等の機能を持つことができる．当然，RDOを介したデータベースアクセスにも対応している．しかし，RDOが使用するODBC接続はインターネットをまたぐことができない．それに動的にダウンロードされたとしても，クライアントサイドのODBC設定の設定やドライバのインストールの問題が残る．

Advanced Data Connectorによるプロトタイプ

　そこで，考えたのが先月号で紹介したADC（Advanced Data Connector）との併用である．動的にダウンロードされたプログラムはADCを使ってHTTP経由でデータベースへのアクセスをおこなう．ADCの接続情報としてODBCのDSNを要求するが，それはサーバーのDSNであって，クライアントのDSNではない．つまり，クライアントサイドでのODBC設定は必要ない．
　現在の英語版では2バイト文字を取得すると文字情報が誤って伝送され，余分な記号が附加されるという障害があったが，これは独自のパッチをあてることで解決した．しかし，できあがったプロトタイプの性能はさんざんなものだった．セッションの確立のために生じるオーバーヘッドが大きすぎるのである．コンボボックスのリストにデータベースのテーブル内容を取得する負荷の大きいプログラムだったが，ひとつのフォームのオープンに1.5分かかるのは問題だった．最適化の方法はいくつか思いついたが，効果には限界がある．
　この結果に対してはいくつかの釈明をおこなう必要があるだろう．私が使用したのはhttp://microsoft.com/adcで入手したリリース1.0である．ベータ1.5も公開されていたが，これは動作させることができなかった．リリース1.0は動作したが，そのすべての機能を使用できるわけではなかった．結局，私としては確実に動作するSQL文の実行機能だけを使用して，プログラミングをおこなった．だから，実装されているはずのレコードセットによる更新がスマートに実現すれば，パフォーマンスが劇的に向上する可能性は高い．私はいまだにADCの可能性に高い期待をしている．
　しかし，とにかく，私と妻の2人は翌日，関係者にみせるためのプロトタイプを作成しなければならなかった．ActiveX DocumentsとADCによるプロトタイプのコーディングを，Visual Basicプログラマである妻が終了させたのは明け方の5時だった．我々はそれからテストをおこない，絶望的な結果を得ることになる．

HTMLのフォームで不定数のSQL文を実行

　何かの代替案を考えなければならなかった．問題となるのは，数が特定できない複数のSQL文をサーバー側で実行しなければいけないということである．それならば，複数のSQL文をひとつのストリングに結合してサーバーに送信し，それをサーバー側で切り出せばいいではないか．
　経験的にいってASPは安定して動作し，処理は十分に高速である．次のポイントはASPが返した結果をどのようにインターフェイスに反映させるかである．VBSで配列を操作し，表形式に並べたHTMLのオブジェクトに表示する方法も考えたが，現在のInternet ExplorerがサポートするVBSの安定性から考えると不安な処理だった．それに，HTMLのオブジェクトはプログラミングの柔軟性も低い．
　次に考えたのがテキストボックスなどのActiveXコントロールをHTML上に配置し，VBSで値を代入していく方法である．この方法の問題点はActiveXコントロールをHTMLやHTMLレイアウトコントロール上に配置すると，フォーカス関係のイベントが取得できない点である．フォーカスを失ったときのイベントが取得できないのは，業務プログラムのインターフェイスを作成するには大きすぎる制約である．
　結論からいえば，フォームをActiveXコントロールとして作成し，各コントロールのプロパティを公開して，値の設定と取得をInternet Explorerに記述されているVBSでおこなうことができるようにしたのである．入力に関するフォーム内での処理は，すべてVisual Basic 5.0で記述し，ActiveXコントロールとして実装する．また，サーバー側で実行するSQL文もすべてコントロール内で生成してしまう．HTMLのサブミットによって，その値をサーバーに送信し，ASPはActiveXコントロール化されたフォームに結果を代入するVBSを動的に生成する．

ActiveXテクノロジーのオールキャスト

　これが，結果として考えたシナリオである．まさにActiveXテクノロジーの百花繚乱である．
　この方法の問題点として次のようなことがあげられる．

ActiveXテクノロジーに依存するため，ブラウザとOSが限定される

　インターネット対応といっても，この場合，ユーザーが望んでいるのはプロパイダを使った低価格WANの実現であり，不特定多数のユーザーを相手にするものではない．公開するのならば，ASPなどを使ってブラウザやOSに依存しないシステムを作成すべきだろう．その際にインターフェイスの柔軟性に難がでるのはやむを終えない．
　ユーザーがWindows用のInternet Explorer専用で納得してくれるならば，この2つの問題点には譲歩する余地がある．
　もっとも，ADCを使用してもこれらの問題が完全にクリアさるというわけではない．

データ表示の仕組み

　プログラムの仕組みはかなり複雑である．動作の原理は図2を参照してほしい．
　最初にページがロードされたとき，ブラウザのFRAME1はdbaccess.aspをActive Serverに要求する．サーバーはASPファイルに記述されているスクリプトを実行してクライアント用のVBSコードを動的に生成し，FRAME1にロードする．FRAME1にロードされるActive Server PagesにはVBSのスクリプトが記述されているだけなので，FRAME1には何も表示されない．しかし，Window_onLoadプロシージャに記述されているコードが実行され，データベースの内容をActiveXコントロールのフォーム（cxForm）のテキストボックス（txt1）に表示する．データ表示部はこのように動作する．

図2：プロトタイプの動作原理図

データ更新の仕組み

　データ更新のためにはSQLのUPDATA文とSQLを利用する．データが変更された場合，変更したレコードと新規に作成したレコードのそれぞれにフラグを立てておく．単数レコードしか表示しないようなケースでは問題ないが，グリッドコントロール等を使用して複数レコードの編集を可能にした場合には，どのレコードが編集され，どのレコードが新規に作成されたかを把握しておく必要がある．
　このフラグはHTMLのサブミットボタンがクリックされて，SQLcmdプロパティの値取得が要求されたときに参照する．
　たとえば次のように「商品」テーブルが編集されていたとする．

商品コード	商品名	価格	フラグ
1	いちごクッキー	300	更新
2	リンゴパイ	200
3	チョコットクッキー	230	削除
4	ショートパイ	140	新規

　SQLcmdプロパティを取得するとActiveXコントロール（acxForm）は，UPATE，DELETE，INSERTの3つのSQLステートメントをひとつのストリングに結合して，HTML内のVBSコードに提供する．VBSは取得した値をHIDDEN属性の<INPUT>タグに格納し，文字列をサーバーに送信する．
　図では省略しているが，サーバーサイドでは区切り文字によってSQL文を各行ごとに分割し，複数回数のSQLコマンドを実行する．対象のデータベースがMS SQL Serverならば，各ステートメントを「GO」で区切っておけば，SQLステートメントを切り出す必要がない．これにより，念願だった複数行の同時更新が可能になる．
　VBSのコードをやりとりするASPを別フォームにロードしているのは，ActiveXコントロールが表示されているフォームが更新ごとにリフレッシュされるのを防ぐためである．

ActiveXコントロールによるフォーム

図3：開発中のActiveXコントロールによるフォーム

　実際に作成したプロトタイプが，この記事の冒頭に掲載している図1のプログラムである．ページはサブミットボタン以外はすべてActiveXコントロールで作成されている．このActiveXコントロールフォームのグリッド表示部には，文化オリエント社のSpread OCXを使用している．もちろん，データベースとの連結はしていない．ActiveXコントロールフォームをVisual Basic5.0で開発している様子が図3である．
　このフォームはデータの表示編集機能とSQL文を生成する機能を持っている．それらを操作しているのは，すべてクライアントサイドのVBSである．このVBS自体が，データベースにアクセスするASPにより動的に生成されている．
　プロトタイプのレベルでは，プログラムの動作は十分に高速で安定している．ただ，仕組みが複雑なだけにプログラミングは若干混乱しやすい．しかし，トリッキーな処理はなく，各開発ツールごとの標準的な機能しか使用していないので危険は少ない．データアクセスにはASP+ADOを用いており，どのような環境でもインターネット経由でのアクセスが可能である．

最後に

　このプログラミング方法は，現時点でインターネット経由でアクセスするWebデータベースプログラムを作成しなければならない開発者には有効な方法である．しかし，IDCがそうであつたように，この方法も所詮は過度期の手法である．将来的にはADCやJDBCのようにクライアントサイドで自由にレコードセットを操作できる方法が主流になるだろう．
　しかし，本命の登場を待っていてはいつまでも開発にかかれないのが，現代の開発者が置かれている状況である．現在，提供されている技術の組み合わせで，できる限り使いやすいシステムを開発していく努力は必要だろう．
　なお，Webデータベースシステムの長所であるアプリケーションの自動配布を実施するためには，CABファイルを作成する必要がある．自動ダウンロードおよび，インストール可能なCABファイルを作成するにはVisual Basic付属のセットアッブウィザードを使うのが一般的である．しかし，私が使用しているリビジョンのVisual Basic 5.0に付属しているセットアップウィザードで作成するCABファイルでは，正常に自動インストールがおこなわれなかった．特にサードパーティ製品であるSpread OCXの自動インストールの方法がわからなかった．
　CABファイルを自分で作成するには，ActiveXSDKに含まれているDiamond.exeというツールを使用するる．操作方法は添付のドキュメントに記述されている．INFファイルの作成法さえ理解してしまえば，作成は難しくない．このツールで作成したCABファイルだと，サードパーティのOCXやVisual Basic5.0のランタイムライブラリも問題なく自動的にクライアントマシンにインストールできる．
　また，バージョン番号を設定することで，バージョンが上がっている場合のみインストールするといった設定も可能である．こういった，メインテンナンスを軽減してくれるようなシステムの発達は，喜ばしいばかりである．しかし，その恩恵の裏側に，セキュリティホールという闇が隠れていることも忘れてはならない．