DOBON.NET DOBON.NETプログラミング掲示板過去ログ

AddWithKeyにて主キーが取得できない

環境/言語:[VS2010 C# WindowsXP、7]
分類:[.NET]

オラクルのテーブルに対してCommandBuilderを使って更新するプログラムを作成中ですが、データ更新時に以下のエラーが出ています。

「UpdateCommand の動的 SQL 生成は、キーである列情報を返さない
 SelectCommand に対してサポートされていません。」

※Microsoft ODBC for Oracle ドライバーにて接続

現象は特定のテーブルにおいてのみ発生しております。

Fillの前にMissingSchemaAction.AddWithKeyを付与していますが、取り込んだデータセットの中には主キーが取り込めていませんでした。

試しに該当のテーブルにアクセスで接続してデザインモードでみたところ、主キーが見えています。

ヘルプで以下の記述を見つけました。

----------------------------------------------------
.NET Framework OLE DB 用データ プロバイダで AddWithKey が
正しく機能するためには、ネイティブな OLE DB プロバイダが
DBPROP_UNIQUEROWS プロパティを設定して必要な主キー情報を取得し、
IColumnsRowset 内の DBCOLUMN_KEYCOLUMN を調べてどの列が主キー列かを確
認する必要があります。DataTable ごとに主キー制約を明示的に設定するこ
ともできます。これにより、既存のレコードと一致する入力レコードが、追
加ではなく更新されるようになります。

----------------------------------------------------
上記の内容について、具体的にどこで何を見ればいいのか不明です。
アプリ側でしょうか?DB側でしょうか?
ご教示いただきたく、よろしくお願いします。

VS2008 C# Win7 
とりあえず…
MissingSchemaAction.AddWithKeyは関係ありません。
DataTableへの列情報&主キー情報付加はCommandBuilderでのSQL生成とは無関係です。
(そっちはそっちで必要なものだと思いますが、別の話。)

どのようなSELECT文を指定したのでしょうか。
「DataTableへの列情報付加」にしても「CommandBuilderでのSQL自動生成」にしても、
どちらもそれぞれ、結局は元になるSELECT文の内容次第です。
色々結合しちゃったりしてると「一体何をもって主キー?だいたい、更新相手のテーブル自体、どれなのよ?」
とかいう話になるので無理だと思います。
またそもそも、主キーのはずの列はSELECT文でSELECT対象に入っていますか?
(MissingSchemaAction.AddWithKeyでのFill時情報付加についても、ない列に対しては行えませんので。)


ちょうどよいURLがありました。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1036773420
これのベストアンサーが、CommandBuilderの方のお話で、別の回答がDataTable側(MissingSchemaAction.AddWithKey云々)のお話です。
ご回答、ありがとうございます。

この現象についてはAサーバのDB環境に対して接続している場合は現象が発生しておらず、正常に更新できるのですが、Bサーバの場合、発生しています。ABのDB環境は同じと思いたいのですが、構築者が異なるため、何かの差異が発生しているのではないかと想像しています。

> どのようなSELECT文を指定したのでしょうか。
単一テーブルについて単純に全フィールドを指定して抽出するのみのSQLです。

> またそもそも、主キーのはずの列はSELECT文でSELECT対象に入っていますか?
A,Bサーバともに主キーが存在しており、SELECT対象です。Aサーバではアプリからの更新もできています。

> ちょうどよいURLがありました。
> http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1036773420
> これのベストアンサーが、CommandBuilderの方のお話で、別の回答がDataTable側(MissingSchemaAction.AddWithKey云々)のお話です。

こちらも参照しています。

上記のため、DB環境の差異による問題のようにも思います。それを調べたく、ヘルプ記載のDBPROP_UNIQUEROWS プロパティ等について情報がほしいのですが。

情報をお持ちの方いらっしゃいましたら、よろしくお願いしますm(__)m。
こんにちは。

複数のサーバで動作が異なる話だとは思いもよりませんでした。…。
お役に立てませんが、以下とりあえず。

環境差異の可能性がご自分でも考えられるのであれば、よそよりも目の前に「最大の情報」があるのでは。
両方の設定等を比べてみれば違いがあるかないか判ると思いますが。
同じと思いたいとかではなく、同じであることをまず確認してから他へ当たる方がよいと思います。
全部だと気が遠くなるかもしれませんが相手がうまく行かない方のサーバでも他のテーブルはうまく行っているのであれば
見比べる範囲はごくごく狭いと思うので、
Accessでのデザインで簡単なテーブルの情報を見る程度ではなく
Oracleのツールでそのテーブルと各列について各部完全に(詳細に)比較してみてください。

もしくは、よく判らなくて見比べきれない場合
うまく行かない方のOracle上で新しく、
・うまく行かないテーブルひとつ
・うまく行くテーブルひとつ
をそれぞれ「元と同じと思える」形で作成してそれらに対して適当なレコードを作っておいて、
プログラムでコマンドビルダーを使って同じ処理を行ってみるとか。
この際、テーブル自体の細かい設定は写し取らずに列の型や精度、キーの設定等のみ
を写し取って、極小のCREATE文で定義してください。
両方うまく行くか両方うまく行かないならテーブル自体のプロパティに何か設定しなければならない部分があるのでしょうし、
相変わらず件のテーブルの方だけがうまく行かないなら
そのテーブルの列の定義や列に関する制約の定義の中におかしい部分かODBCではサポートしきれない何かがあるのかもしれません。


なお、「DBPROP_UNIQUEROWS」はみぅみぅさん自身がさきに引用した部分を読んでも書いてありますが
ODBCプロバイダではなくOle DBプロバイダでのプロパティです。
(※そもそも特定のテーブルでのみうまく行かないだけで、
Bサーバでも他のテーブルでは主キー情報がきちんと受け取れて更新コマンドを生成できているんですよね?)
とん。さん

お世話になります。丁寧なご回答、ありがとうございました。

やはり、環境の比較は必要ですよね。残念ながら私が現地に行くことができず、以来をしている状態なのでなかなか思うように調査が進んでおりません。また、顧客稼働環境なため、あまりテスト的なものを作成することもできず・・・。
リモートではありますが、引き続き調査を継続します。

> なお、「DBPROP_UNIQUEROWS」はみぅみぅさん自身がさきに引用した部分を読んでも書いてありますが
> ODBCプロバイダではなくOle DBプロバイダでのプロパティです。
これはどこからか設定を見ることができるのでしょうか。


> (※そもそも特定のテーブルでのみうまく行かないだけで、
> Bサーバでも他のテーブルでは主キー情報がきちんと受け取れて更新コマンドを生成できているんですよね?)
はい、その他のテーブルについては全く問題がない状態です。一つのテーブルのみについて問題が出ております。

DOBON.NET | プログラミング道 | プログラミング掲示板