再度ＸＱｕｅｒｙ・・・

　梅雨の鬱陶しい季節ですが、皆さん如何お過ごしでしょうか？
　さて、私のほうは、この何ヶ月にわたり受託開発していたシステムの納品も済んで、少し落ち着いているところでしょうか？

　ところで、このブログもなかなかこまめに投稿できず、かなり不定期的連載となっています。（申し訳ありません）
　思えば、前回から一月も経ってしまいました。でも今回はご安心下さい。すでに書ききれないので、近日「続き」を書かないといけなくなりました。ｗ

　ところで、この連載の始まった頃からの課題といいますか、ＸＭＬデータベースの使い方の中で、「これは、どうすればいいんだ・・・？」と疑問に思いながら追求していたことが幾つかあったんですが、そのうち一番大きいやつがこのほど、霧が晴れたように解決してしまいました。
　まぁ、この連載も手探りでやっていますので、どこに行き着くかも分からないんですが、それがまた楽しいのかも・・・w
　ということで、今回は、再びＸＱueryがテーマです。（正確には「今回から」＝「次回も・・・」？）

「ＲＭ互換」のタスクの検索・・・

　たまたまテーマにしてるのが、ＭＡＧＩＣ　Ｖ１０のソースの解析なんですが、プログラムのソース（＝ＸＭＬドキュメント）をＸＭＬデータベースに格納することにより、効率良く該当ドキュメントを検索することが可能になることは、今までの連載の中で述べてきたとおりです。
　ここで、その要点をまとめておきます。

• ＸＭＬドキュメントは、ＸＭＬデータベース（ＤＢ２　９）のＸＭＬタイプのカラムにそのまま格納することができる
• 該当するドキュメントは、ＳＱＬを拡張したＳＱＬ／ＸＭＬを使用することにより検索が可能
• 具体的には、ｗｈｅｒｅ句でxmlexist関数を使い、ＸＰａｔｈで指定する

　最近、某ＭＬで、「ＲＭ互換のタスクをどうやって探せばいいか？」という話題になりました。
　「ＲＭ互換」というのは、古いバージョンのコーディング方法をサポートするために、ＭＡＧＩＣ Ｖ１０で実装された機能？で、純粋なイベントドリブンコーディングにするためには、取り除くことが望ましいとされているものです。
　私は思わずその問いの答えとして、「ＸＭＬデータベースを使って検索すれば・・・」という回答を投げたんですが、かろうじてシスオペの方に反応して頂くに留まりました。（ＤＢ２ ９をいじっているＭＡＧＩＣの技術者はまだ少ないと思うので・・・。いや、はたして、いるのかどうか？）
　まぁ、機会ある度にＤＢ２ ９の宣伝・普及活動はしようと思っていますので、半分目的は遂げられたんですが・・・。ｗ

　さて、この「ＲＭ互換」という機能は、良く出来ているというか、不思議な機能というか、普通のＶ１０のコーディングであれば作成できないんですが、隠しスイッチ（MAGIC.INIに記載）で入力できるようになります。

[MAGIC_SPECIALS]SpecialRMCompatibleLogic = Y

　「ロジックテーブル」に１つだけ挿入が可能で、挿入すると自動的にデータビューの内容（パラメータ、変数、メインソースやリンクしたテーブルのカラム）が自動的に展開されます。そして、その中に項目更新やズームなどの従来レコードメインというロジックテーブルに記載していた内容を記録できるようになります。下の図は、ブロックとコールタスクを挿入した例です。


　しかし、面白いのは画面上とソース上では、記載される場所が違うという点です。
　つまり、ＲＭ互換に記載したロジックは、「LogicUnit/Level/@va」lが"R"でかつ、「LogicUnit/Type@val」が"M"の「TaskLogic」（いわゆるレコードメイン）に記載されます。


　これに対して、ロジックテーブルのＲＭ互換そのもの（「LogicUnit/Level/@va」lが"M"で、「LogicUnit/Type@val」は存在しない）は、ごくわずかなその属性値が記載されるだけです。その記載の有無が問題となるのではないかと推測します。

　さて、ということで、「ＲＭ互換のあるプログラムの検索」を行うためにはどうすれば良いか？という問題に戻ります。
　下のＳＱＬ文がその答えです。

select c.DATAID from DB2ADMIN.XMLDBTEST c where 
 xmlexists('$i/Application//LogicUnit/Level[@val="M"]'
 passing c.DATAXML as "i")

　上記のコマンド中、「Application//LogicUnit」とある、「//」はどういう意味でしょうか？
　これは、任意の階層のタグを現すXPathの表現です。
　ＭＡＧＩＣのプログラムのソースが悩ましいのは、タスクの記述が再帰的に記載されることです。
 ルートタスクは、「Application/ProgramsRepository/Programs/Task」ですが、孫タスクは、「Application/ProgramsRepository/Programs/Task/Task/Task」です。でも子供が３人いて、孫は全部で１０人かも知れません。
　「LogicUnit」は「Ｔａｓｋ」の子の「TaskLogic」の下に作成されますが、「Application//LogicUnit」は、全ての任意のタスクの下にある「LogicUnit」を意味します。
　もしかしたら、途中を省略せずに「Application//Task/TaskLogic/LogicUnit」にしたほうが良いのかもしれません。
　「Level[@val="M"]」は、属性値が「M」である「Ｌｅｖｅｌ」ノードを意味します。この"[" "]"で条件を特定させます。
　ここまでは、おさらいですね。
ところで、「ＲＭ互換」タスクが同じプログラム中に複数個存在したとき、それを検索するにはどうすれば良いでしょうか？当然、大きなプログラムであれば、何十というタスクが存在するかも知れません。
　上のＳＱＬ文では、プログラム（ドキュメント）のある行（レコード）は返ってきますが、それがどこのタスクにあるのかまでは分かりません。

　実は、これが、私の当初からの悩みだったのです！

　で、ちょっと前までは、検索されたドキュメント（＝プログラムソース）をゴリゴリと分析することを考えていました。
　ところが、もっとスマートな方法があったんですね・・・。

（ということで、次回につづく・・・）

DB2 Star Festival 2007

　来週の月曜日に、ＩＢＭさん主催のイベントがありますね。（私も参加します！）

　去年の「Viper Night」に参加したのがＤＢ２ ９との出会いでしたが、今度のイベントでもまた「新しい出会い」があるといいな・・・と楽しみにしています。