[pgsql-jp: 40453] Re: 自作関数nvlの挙動について
toshihideka4316 @ zenrin.co.jp
toshihideka4316 @ zenrin.co.jp
2010年 10月 15日 (金) 15:53:08 JST
お世話になります。片山です。
> 気になってはいたのですがなかなかチェックしている余裕
> がありません。まずは最新のODBCドライバを試してみて
> ください。
> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/indexj.html
> の8.4.0202に向けて確認テスト中のドライバ
ODBCドライバ8.4.02.02でCOALESCE関数を使用して動作検証を行いましたが、以前と同
じ条件でAPが異常終了しました。
↓
>1回のSQL発行で、120行程度のレコードが返却され、100件までがnumeric型で8桁、
>101件以降がnumeric型で9桁のレコードとなっております。このパターンでレコード
が取得できる場合でNVLを
>使用している場合のみAPが異常終了します。
桁数について動作検証を行いましたので情報展開させていただきます。
#テスト用のテーブルに1〜100件目と101件目のデータで桁数が異なるように101件の
データを挿入して、ODBC接続で接続しCOALESCE関数を使用するSQLを発行しました。
(UseDeclareFetch=1を接続文字列で設定)
1〜100件目の桁数:101件目の桁数⇒結果
9桁 :10桁 ⇒エラー
3桁 :9桁 ⇒エラー
3桁 :8桁 ⇒エラー
3桁 :7桁 ⇒エラー
3桁 :6桁 ⇒エラー
3桁 :5桁 ⇒正常終了
3桁 :4桁 ⇒正常終了
5桁 :6桁 ⇒エラー
1桁 :5桁 ⇒正常終了
1桁 :6桁 ⇒エラー
9桁 :9桁 ⇒正常終了
↓
以上の結果より、
桁数が1〜5、6〜9、10のグループを跨いだ場合エラーになるのではと予想します。
#使用したテストテーブルの宣言
CREATE TABLE testdb.testtable(
mido numeric(10)
)
#発行したSQL
select COALESCE(mido,-1) as MIDO from testtable order by MIDO
#井上さんには別途Mylogを送信させていただきます。
以上です。
> -----Original Message-----
> From: pgsql-jp-bounces @ ml.postgresql.jp
> [mailto:pgsql-jp-bounces @ ml.postgresql.jp] On Behalf Of Hiroshi Inoue
> Sent: Friday, October 15, 2010 12:34 PM
> To: pgsql-jp @ ml.postgresql.jp
> Subject: [pgsql-jp: 40451] Re: 自作関数nvlの挙動について
>
> 井上です。
>
> 気になってはいたのですがなかなかチェックしている余裕
> がありません。まずは最新のODBCドライバを試してみて
> ください。
> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/indexj.html
> の8.4.0202に向けて確認テスト中のドライバ
>
> それでも現象が発生するようでしたらMylogを取得して
> 直接私に送っていただけませんか。
>
>
> (2010/10/15 11:28), toshihideka4316 @ zenrin.co.jp wrote:
> > お世話になります。片山です。
> >
> > スタックトレースの調査はまだ行えていませんが、
> > 調査を進め新たにわかったことがあるので展開させていただきます。
> >
> > 接続文字列にFetch=1000を追加して、SQLを実行した場合は自作のNVL、 COALESCE
共に
> > 正常に動作しました。
> > (APの異常終了なし)
> > デフォルトでは、設定値がFetch=100である為、以下の現象の「100」と関係ある
ので
> > はと考えています。
> >> 1回のSQL発行で、120行程度のレコードが返却され、100件までがnumeric型で8
桁、
> >> 101件以降がnumeric型で
> >> 9桁のレコードとなっております。このパターンでレコードが取得できる場合で
NVL
> > を
> >> 使用している場合のみAPが異常終了します。
> >
> > 予想としては、DeclearFetch=1の場合、最初にFetchで設定された、
> > レコード数で取得した範囲のレコードで何らかの領域確保を行って処理をしてい
るこ
> > とが原因ではと考えております。
> >
> > 当情報でなんらかヒントになる情報等ありましたらご提供お願いいたします。
> >
> > 以上で失礼いたします。
>
>
>
>
pgsql-jp メーリングリストの案内