- PR -

ODP.NET経由でStoredProcedureに全角文字列を渡すとエラー発生

1
投稿者投稿内容
犯人はヤス。
会議室デビュー日: 2006/12/20
投稿数: 3
投稿日時: 2006-12-20 09:23
現在 VS.NET2003,Oracle10g(10.2.0.1.0),ODP.NET(10.1.0.4.0)にてWEBシステムを構築中です。

DBのCHARSETはUTF8、ASP.NETのWeb.Config<globalization requestEncoding="utf-8" responseEncoding="utf-8" />と設定しています。

この環境で、OracleのNvarchar2をInput引数に持つStoredProcedureに対し、
Parameters.Addメソッドを利用、OracleDbType.NVarchar2と型指定を行い、
全角文字列(「あああ」等)のデータをBindしています。

この状態で処理を実行(StoredProcedureをCall)すると、下記のエラーメッセージが表示されます。
「ORA-01460: リクエストされた変換はできません。 」

デバッグで追いかけたところ、実際にCallされるまでは、思った値(「あああ」等)が入っているようでした。
ですので、Bindされた値がOracle上で利用される際、何らかの不整合が起きているのでは無いかと考えています。
※ちなみに、「abcd」等の1Byte文字をBindした場合はエラーは発生しません。

同様の症例を経験された方、何か思い当たる節がある方、何か思いつくことがあられる方がありましたら何かアドバイスをいただけませんでしょうか？
未記入
大ベテラン
会議室デビュー日: 2006/12/15
投稿数: 157
投稿日時: 2006-12-21 19:05
１、ストアドをSQL-PLUSで直接実行した場合は動作しますか？
２、>DBのCHARSETはUTF8
　　デフォルトキャラセットですか？各国語キャラセットですか？
　　Nvarchar2は各国語キャラセットで変換された気がします。
犯人はヤス。
会議室デビュー日: 2006/12/20
投稿数: 3
投稿日時: 2006-12-21 21:55
>未記入様
回答有難う御座います。

>１、ストアドをSQL-PLUSで直接実行した場合は動作しますか？
動作します。
現在、StoredProcedureを利用するのを避け、
暫定で直接SQLを発行することで逃げています。
Bindを利用しないことのデメリットを考えると、どうしても原因が解明して欲しいところです。


>２、>DBのCHARSETはUTF8
>　　デフォルトキャラセットですか？各国語キャラセットですか？
両方ともUTF8指定です。


何か思いつかれましたらそのときは宜しくお願い致します。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2006-12-22 00:05
NAL-6295です。

こんばんは。

まず最初に、今回の件と

引用:

<globalization requestEncoding="utf-8" responseEncoding="utf-8" />


に因果関係はありません。

ちなみに、.NETのString型はUTF-16で表現されていたと思います。

また、使用になられている

引用:

ODP.NET(10.1.0.4.0)


は、
http://otn.oracle.co.jp/software/tech/windows/odpnet/index.html
を見ると、かなり古いバージョンのようですね。
Oracle Data Provider for .NET 2.0 10.2.0.2.20
が最新のようです。
未記入
大ベテラン
会議室デビュー日: 2006/12/15
投稿数: 157
投稿日時: 2006-12-22 11:29
忘れてましたが、最新のODPとは別にODT（ODP含）が提供されているので、VSからストアドを
テストしてみるのも手ですね。
ストアド単体では動いているのでODPが原因だとは思いますが。

色々な掲示板で似たような傷害が報告されてましたが、解決には至ってないようで・・・
犯人はヤス。
会議室デビュー日: 2006/12/20
投稿数: 3
投稿日時: 2006-12-23 08:40
>NAL-6295様
はじめまして。おはよう御座います。
せっかくご返信頂きましたのに、お礼の方が遅れてしまいましたことをお詫び申し上げます。

・因果関係の件
globalizationの設定はクライアント/サーバ間のRequest/Responseの通信に関するもので、
今回の件はサーバに到達した後、
UTF-16で扱われているVB.NET側String型のデータとOracle上のNvarchar2との問題という解釈で宜しいのでしょうか？

・ODP.NETのバージョンの件
「for .NET 2.0」の一文を見て、最初に除外してしまっていました。
先ほどダウンロードし、参照設定を変更してみたところ、思ったように動作するようになりました。
自分の調査不足のために発生した遅延時間を悔やむばかりです。

貴重なアドバイス、有難う御座いました。


>未記入様
・ODTによるVSからストアドをテスト
このようなことが出来ると言うのを全く知りませんでした。
使い方を勉強してみたいと思います。

・ストアド単体では動いているのでODPが原因だとは思いますが。
結果、まさにその通りだったようです。
上の部分でNAL-6295様に返信させて頂いた内容に記述した通り、ODP.NETの最新Versionが掲示板投稿時点に利用していたものと思っていたため、
ミドルウェアへの疑いが薄れてしまっていたようです。

・他の掲示板での障害報告
私と一緒な原因の方はいらっしゃらないのでしょうかね・・・。
「Oracle Data Provider for .NET 2.0 10.2.0.2.20 」の表記が
「Oracle Data Provider for .NET 2.0 (and 1.x) 10.2.0.2.20 」などと書いてあれば・・・。
と思ってみたりしました。

いずれにしても、固定観念が今回の問題発生の理由となっていたことに違いはありませんので、
上位Verからの下位互換もしっかりと確認すべきであったと思い直しています。

ご回答頂きました皆様、今回はありがとう御座いました。
NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2006-12-23 09:54
引用:

犯人はヤス。さんの書き込み (2006-12-23 08:40) より:
・因果関係の件
globalizationの設定はクライアント/サーバ間のRequest/Responseの通信に関するもので、
今回の件はサーバに到達した後、
UTF-16で扱われているVB.NET側String型のデータとOracle上のNvarchar2との問題という解釈で宜しいのでしょうか？


そういう解釈でよいと思います。
そうやって、問題点を切り分け、切り分け狭くしていくと解決するのが、楽なんですよね。

結果的に新しいODP.NETで解消されたようで、よかったです。
1

スキルアップ／キャリアアップ（JOB@IT）