[pgsql-jp: 26110] Re: 7.2 ODBC ドライバで SQL_DESC_OCTET_LENGTHを取得すると 0 になる。

[Tetsuya Kakura]

加倉です。

Hiroshi Inoue wrote on Fri, 24 May 2002 09:32:35 +0900

> > > 転送バッファの最大サイズなら、254
> > > で丸める意味はないとおもいますが。
> > > OCTET_LENGTH で最大バイト数が分からないと、VARCHAR 型のデータは
> > > SQLBindColではデータを取得しずらくなってしまいます。
> 
> > 確かにおっしゃるとおりなのですが、ODBCでは254を境に
> > SQL_VARCHARからSQL_LONGVARCHARへと別の扱いになって
> > しまいます。そして不幸なことにSQL_LONGVARCHARを
> > SQL_VARCHARほどうまく扱えないアプリが多いのです。
> > VARCHARだから最大文字数に達するデータがあるかどうか
> > もあやしい。３倍になるのは最悪のシナリオに過ぎずす
> > べてasciiなら１倍ですんでしまう。7.1からの単純コン
> > バージョンなら元々バイト数も足りているはずである。
> > そもそも7.1迄はそうだったのだし文字数とバイト数を
> > 区別しないユーザーもいるだろう。等々を勘案して現在
> > の内容にしています。たいしたものをうまないこういう
> > 所で悩まなければならないのにはいつもうんざりする
> > のですが。
> 
> 上のように折角苦労してもOCTET_LENGTHを問い合わせない
> アプリには意味がありません。例えばMS Accessでリンク
> テーブルを表示してもOCTET_LENGTHの問い合わせは行なわ
> れません。加倉さんのおっしゃるように254でまるめなく
> ても影響はさほどないかも知れません。それにしても
> ３倍になるというのは気が重いですが。

えーと、いま私が作ってるツールが参照します。(一般用じゃ
ないけど)
SQL_LONGVARCHAR をうまく扱えないアプリが多いなら、
SQL_VARCHAR で正確な情報を返したほうが正しく扱ってもら
える可能性は多いのでは？（ただの憶測です。すみません)

# アプリ側が SQLBindCol ではなく、全てを SQLGetData で
# 取得するようにしたら COLUMN SIZE, OCTET LENGTH など
# 気にせずにデータを取れるのでしょうね〜
# 私が作っているのは SQL_LONG**** は SQLGetData で取得
# しますが、他の方は SQLBindCol を使ってます。

--
Tetsuya Kakura / kakura ＠ saki.netwk.ntt-at.co.jp