System i SQL G/Wにおける数値項目
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
otamth
投稿数: 46
投稿数: 46
ISHIJIMAさん、こんにちは
sum()関数を使用した一応の結果を教えていただきましたのでアップします。
----------------------------
いろいろいじってみましたが、計算の出力先のバッファが１６バイトのPacked
Decimal形式に固定されているようです。
ＡＰＧを使わずに変数を手動で作成（numeric）、出力パラメータに指定してみても結果は一緒でした。
この場合、形式をPacked Decimalの31桁（内部16バイト）に変更したところ、集計結果が表示できました。
こちらでNumeric等他の数値形式に変えても、埋め込みSQL側で16バイトのPackedDecimalで入れてしまっているような感じです。
とりあえず、System iの埋め込みSQLでのSUM関数の出力先は、16バイトのPackedDecimalしか使えないようです。
バッファサイズはCOUNT、MAX等それぞれの関数によって違うようです。
COUNTは４バイトのString Integer、MAXは４バイトのPacked Decimalが取られました（MAXは比較する値の桁数によって変わると思います）。
-------------------------
ただＦ８のエラーチェックをかけますと、数値サイズは１８桁までですというのが表示されます。これは無視して結果オーライのようなことで行うしかないようです。
以上の方式で収束しましたのでご連絡いたします。
ISHIJIMAさんには大変お世話になりました。
sum()関数を使用した一応の結果を教えていただきましたのでアップします。
----------------------------
いろいろいじってみましたが、計算の出力先のバッファが１６バイトのPacked
Decimal形式に固定されているようです。
ＡＰＧを使わずに変数を手動で作成（numeric）、出力パラメータに指定してみても結果は一緒でした。
この場合、形式をPacked Decimalの31桁（内部16バイト）に変更したところ、集計結果が表示できました。
こちらでNumeric等他の数値形式に変えても、埋め込みSQL側で16バイトのPackedDecimalで入れてしまっているような感じです。
とりあえず、System iの埋め込みSQLでのSUM関数の出力先は、16バイトのPackedDecimalしか使えないようです。
バッファサイズはCOUNT、MAX等それぞれの関数によって違うようです。
COUNTは４バイトのString Integer、MAXは４バイトのPacked Decimalが取られました（MAXは比較する値の桁数によって変わると思います）。
-------------------------
ただＦ８のエラーチェックをかけますと、数値サイズは１８桁までですというのが表示されます。これは無視して結果オーライのようなことで行うしかないようです。
以上の方式で収束しましたのでご連絡いたします。
ISHIJIMAさんには大変お世話になりました。
投票数:0
平均点:0.00
otamth
投稿数: 46
投稿数: 46
ISHIJIMAさん、こんにちは
Oracleなどとは違い、System i にはビューというのが存在しないんですよ。
Oracleなどとは違い、System i にはビューというのが存在しないんですよ。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
ＳＹＳＴＥＭ ｉをよく知らないので違っていたらすみません。
ＳＱＬ系でビューを利用してＳＵＭ関数とかを利用すると記憶形式は定義していないので勝手に定義取得すると勝手に都合のよい記憶形式になります。
ＳＱＬ系でビューを利用してＳＵＭ関数とかを利用すると記憶形式は定義していないので勝手に定義取得すると勝手に都合のよい記憶形式になります。
投票数:0
平均点:0.00
otamth
投稿数: 46
投稿数: 46
ISHIJIMAさん、こんにちは。
> ちょっと違うかもしれませんがＩＳＡＭ系のＤＢを複写登録してＳＱＬ系のＤＢにすると記憶形式をＮＵＭＥＲＩＣで定義していても変わってしまいますよ（ＩＳＡＭ系の記憶形式とＳＱＬ系の記憶形式が違う場合、ＭＡＧＩＣが勝手に最適な記憶形式にしてしまうのでは？・・・）
仰るとおりで、都度変更しています。
そこでSQL G/Wで定義取得して（定義どおりのNumeric）もsum()関数を使用した結果がすべてPacked Decimalになってしまうんです。
> ちょっと違うかもしれませんがＩＳＡＭ系のＤＢを複写登録してＳＱＬ系のＤＢにすると記憶形式をＮＵＭＥＲＩＣで定義していても変わってしまいますよ（ＩＳＡＭ系の記憶形式とＳＱＬ系の記憶形式が違う場合、ＭＡＧＩＣが勝手に最適な記憶形式にしてしまうのでは？・・・）
仰るとおりで、都度変更しています。
そこでSQL G/Wで定義取得して（定義どおりのNumeric）もsum()関数を使用した結果がすべてPacked Decimalになってしまうんです。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
ちょっと違うかもしれませんがＩＳＡＭ系のＤＢを複写登録してＳＱＬ系のＤＢにすると記憶形式をＮＵＭＥＲＩＣで定義していても変わってしまいますよ（ＩＳＡＭ系の記憶形式とＳＱＬ系の記憶形式が違う場合、ＭＡＧＩＣが勝手に最適な記憶形式にしてしまうのでは？・・・）
定義取得がうまくいっているのであれば問題ないような気がしますが・・・
定義取得がうまくいっているのであれば問題ないような気がしますが・・・
投票数:0
平均点:0.00
otamth
投稿数: 46
投稿数: 46
ISHIJIMAさん、こんにちは。
> System i 開発者ガイドの６１ページから６９ページ当たりが何か関係していませんか？
System i 側には元々Numericで定義してあるものを、ISAM G/Wで定義取得するとそのままNemericで取得できます。この際はテキスト名も表示されるので、これを複写登録してSQL G/Wに変更するとPacked Decimalに変換されてしまうのです。
そこでこれが悪いのかと思い、SQL G/Wで定義取得するとNumericで取得できるのですが、sum()関数を使用したSQLを発行しAPGするとやはりPacked Decimalに変換されてしまいます。
SQL G/Wのバグっぽい？？？
> System i 開発者ガイドの６１ページから６９ページ当たりが何か関係していませんか？
System i 側には元々Numericで定義してあるものを、ISAM G/Wで定義取得するとそのままNemericで取得できます。この際はテキスト名も表示されるので、これを複写登録してSQL G/Wに変更するとPacked Decimalに変換されてしまうのです。
そこでこれが悪いのかと思い、SQL G/Wで定義取得するとNumericで取得できるのですが、sum()関数を使用したSQLを発行しAPGするとやはりPacked Decimalに変換されてしまいます。
SQL G/Wのバグっぽい？？？
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
System i 開発者ガイドの６１ページから６９ページ当たりが何か関係していませんか？
System i は利用したことがないので違っていたらすみません。
System i は利用したことがないので違っていたらすみません。
投票数:0
平均点:0.00
otamth
投稿数: 46
投稿数: 46
V10 SP4b ＋ Sysmtem i SQL G/Wにおける数値項目の扱いですが、データリポジトリにおいてISAM G/Wにてテーブル定義を取得しますとNumericで取得することが出来ますが、これをSQL G/Wで定義取得を実施しますと、Packed Decimalに変更されてしまいます。そこですべての数値項目をNumericに変更せざるを得ません。
そこで
��SQL G/Wで定義取得する際にNumericのまま取得する方法がないのでしょうか？
�△泙燭海離如璽燭鮓気頬箙�みＳＱＬでsum()関数を使用しAPGを実行すると、数値項目の変数が３１桁のPacked Decimalになってしまい、これをNumericに変更してもデータが表示されません。
以上対応をご存知の方、よろしくお願いいたします。
そこで
��SQL G/Wで定義取得する際にNumericのまま取得する方法がないのでしょうか？
�△泙燭海離如璽燭鮓気頬箙�みＳＱＬでsum()関数を使用しAPGを実行すると、数値項目の変数が３１桁のPacked Decimalになってしまい、これをNumericに変更してもデータが表示されません。
以上対応をご存知の方、よろしくお願いいたします。
投票数:0
平均点:0.00