きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

db2sqljprintを叩いてみた

カスタマイザーにかける前に、serに対してdb2sqljprintをやってみた。


どうやらVARCHARとかTIMESTAMPとかは、
データベースに接続する情報がなくても、
Javaの型から推測されているようだ。
たぶん、StringはCHARではなく、VARCHARにとりあえずしておくのだろう。


sqljcustomizerにかけると、
接続したデータベースの情報から、
バラメータに関する情報やらがserに付加された。
桁数とかnullableとか、カーソルに関してとか。
ただし、実行計画みたいなのはserにはない。
あと、serにはタイムスタンプがあった。
なるほど、これが違うと、実行時に怒られるのか。



カスタマイズとか言っても、ヒント句のように実行計画を
意図的に変化させるわけでもないのかな??
まあ、その辺りはこれから何個かのツール使用方法を修得しよう。


あと、色々調べてみたところ、serファイルがあればカスタマイズは出来るみたいで、javaファイルはいらない。


SQLJカスタマイズ用のsqlj.customize.xmlなんてのが出来るんだけど、
.metadataのところにも小難しい書式のファイルも出来る。
あのファイルもSQLJAntScriptの中に突っ込んでくれよ。


RADは、どうやらdb2jcc.jarとか、諸々のクラスパスを自分勝手に設定するみたいだ。
これはかなり酷い。
ターゲットにしてる環境に合わせたいのに、
プラグインとかSQLLIBとかから持って来ると合わせられないじゃないか。


こんなAntを組みたい。
sqljのトランスレートをする。
カスタマイズする。
javaとserは分けてjarにする。


sqlj.tools.Sqljってクラスがあって、
いちおうではあるがsqljについてのバージョン確認も出来そうではあった。
-ser2classは何なのか気になった。
プロファイルキーのような名前のクラスは、
serから出来てるのかな?謎だ。




db2jcc.jarとかdb2jcc4.jarについては、
バージョン確認の方法がしっかりInformationCenterに書いてある。
javaで叩くやり方です。



夕方呼ばれて、SQLJ関連の事象を調べていたんだが、灯台下暗しでした。
たまたまffdcが出て、マメにffdcも見る性格なもんで、
そうしたらさっき管理コンソールからバインドしたデータベースではないデータベース名が出てる。
慌ててデータソースを調べる。
おぉ、神よ、そんな単純な確認ミスか。
そりゃあいくらバインドし直しても「パッケージがありません」って言われるさ。
呼ばれて飛び出て解析するって時は、やっぱり一から確認せねばならんなー。


ちなみに、Type2で繋ぎたかったんだけども、ネイティブが無かった。
/home/*****/sqllib/libとかWebSphere変数にあるんですけど〜、そんなフォルダが無かった。
つーかそんなユーザがいないよね。
違う環境をコピるにもほどがある。頼むぜ、おいおい。


いったんType2で保存したデータソースは、どうもプルダウンで4に変えると、勝手に画面が切り替わってしまいType4に戻せない。
なんだこの挙動は…。ひどいよ。昔からこうなんじゃないかな。仕方ないから消して作り直す。


残念ながら最後まで解析出来ませんでした。
例外を見る限りでは、NOT NULLなところにNULLを突っ込んで怒られてるようではある。
これを見たらアプリのバグだと思ったのだがどうやら違うようだ。
別の環境で動作していたEARを管理コンソールからエクスポートして、
こっちの環境にデプロイ、SQLJのバインド(やや単純に)、サーバー再始動。
主だった環境差異は、こっちがType4であっちがType2であること。
ドライバーはこっちはJCC、あっちは未確認、バージョンはどちらも未確認。
データベースのバージョンは確認していないが、まあ彼ならしっかり同じバージョンに合わせてるだろう。
WebSphereも前に合わせたバージョンから変わっているようには見えない。
確かこっちはスタンドアロンな構成で、向こうはセル構成になってたような気がする。
DDLが違うのかも気にして、いちおうどちらのDBのテーブルもNot Nullになっていた。
さーて、どうしよう。通常のJavaファイルは確実に同一なはずだ。
それなのに、nullじゃないはずのものがnullになるのは何故か?
あぁ、アプリケーションへリクエストの投げ方の違いが無いか見ないとダメだな。
うし、不透明なものを透明にしていこう。