データベース処理の違い (A フィールドと O フィールド/DFU と INSERT)

SQL をインターフェイスにした場合と DFU などの OS/400 伝統のデータへのインターフェイスを使った場合で、データの内容、もしくは属性のチェックのタイミングが異なるものがあります。

また、OS/400 伝統のデータ・インターフェイスを使っていた時代の、データ操作言語は SQL ではなく RPG でした。その場合、書き込みは専ら MOVE 命令によって行われていたわけですが、MOVE の場合は原則的にレジスターの内容を移動させるだけなので、CPYF や SQL インターフェイスでよくあるような CCSID 変換といったようなことは起こりません。
これは実はいいことでもなんでもなくて、要はデータのチェックはその時には行われない、ということの付随した結果にすぎません。結果的に、適切でないデータタイプのフィールドに適切でないデータが入っている、ということが起こる原因になります。

既存のデータベースを Java などで SQL インターフェイスを使って有効利用しよう、という場合にたいてい問題になるのが、A タイプのフィールドに本来 O タイプであるべきデータが入っていることがあり、そのためデータ変換エラーなどで正しく読み出すことができない、というケースです。

今回はそれを題材にとって、どういうインターフェイスでどういうエラーがでるか、ひいては SQL と OS/400 トラディショナルなやり方で何が違うか、とちょっと実験してみました。


A タイプのフィールドと O タイプのフィールドを持つファイルを作成し、正しい形でのデータを入力しました。
同じフォーマットで、データの入っていないファイルをもう一つ作成しておきます。

RPG と DFU

MOVE 命令を使って、A タイプのフィールドを O タイプのフィールドに、O タイプのフィールドを A タイプのフィールドに、それぞれコピーさせます。

上記プログラムを使って、もともと O フィールドに入っていたデータを A フィールドに MOVE すると (これは何の問題もなくできてしまいます)、DFU では見ることができません。
DFU のような OS/400 トラディショナルなデータ処理では、データは読み出し時にチェックする、という考え方であったことがわかります。

同じファイルを RUNQRY してみると ......

表示させることができてしまいます。
ちなみに対話型 SQL (STRSQL) 画面での SELECT 結果でも同様に表示させることができてしまいます。

元のファイルに、再度 A フィールドから O フィールドに、O フィールドから A フィールドにMOVE し戻してみましょう。
これは上記のプログラムの MOVE の相手先を変えたプログラムを作成して行っています。

正しくコピーされているのがわかります。

SQL インターフェイス

同じことを INSERT 文を使って行うと、下の例のようにエラーで実行できません。

このメッセージを見ると、変換先のフィールドへの「文字変換を実行することができない」わけですから、書き込み時のチェックということになりますね。

MOVE を使って A フィールドに O フィールドの内容をコピーしたレコードからは INSERT は可能です。
以下の例は RPG プログラムを使って、A フィールドに、もともと O フィールドに入っていた DBCS データを MOVE してから同様の INSERT を行った結果です。

読み出し時にはチェックされていない、というか、属性だけがチェックされ、そこをクリアしていれば内容はそのままコピーされることがわかりますね。データの内容とのチェックはされていない、ということですかね?!

実際にデータを見てみると、ちゃんと逆になっているのがわかりますね。
その状態でもやはり SELECT での表示は可能です。

[Top Pageに戻る]

Ads by TOK2