0

searchitという次のクエリがあります

SELECT 2 AS sourceID, BLOG_COMMENTS.bID, BLOG_TOPICS.Topic_Title,
    BLOG_TOPICS.LFD, BLOG_TOPICS.LC,
    BLOG_COMMENTS.Comment_Narrative
FROM BLOG_COMMENTS INNER JOIN BLOG_TOPICS
    ON BLOG_COMMENTS.bID = BLOG_TOPICS.bID
WHERE  (BLOG_COMMENTS.Comment_Narrative LIKE @Phrase)

このクエリは実行され、クエリビルダーに正しい結果を返します。ただし、クエリはコードビハインドで実行する必要があるため、次の行があります。

DataTable blogcomments = btad.searchit(aphrase);

表のいずれの列のどの行にもヌルフィールドはありません。テーブルは十分に小さいので、nullデータを簡単に検出できます。bIDはblog_topicsのキーであり、cIDはブログコメントのキーであることに注意してください。

いずれにせよ、これを実行すると、次のエラーが発生します。

制約を有効にできませんでした。1つ以上の行に、null以外、一意、または外部キーの制約に違反する値が含まれています。

テーブルには1xNの関係があり、ブログエントリごとに多くのコメントがあります。DISTINCTを使用してクエリを実行し、戻りフィールドからComment_Narrativeを削除すると、データが正しく返されます（ただし、他の行が必要です）。ただし、他の行を返すと、上記のエラーが発生します。

リターンテーブルには、そこに配置しなかった制約があることを示していると思います。したがって、テーブルの1つに主キーが定義されているため、クエリ自体の呼び出しからその制約を何らかの形で継承している必要があります。持つ必要があります）。しかし、なぜクエリビルダーでクエリが正常に機能するのでしょうか。クエリビルダーは、bIDが結果に重複していることを気にしません（そして、そうすべきではありません）が、コードビハインドは気にします。

補遺：

テストと同じように、

  1. 返品リストからbIDを削除しましたが、それでもエラーが発生します。
  2. blog_topics.bIDから主キーを削除しましたが、同じエラーが発生します。

これは、問題を引き起こしているのは私のbIDがだまされているという事実ではないことを私に教えてくれます。

別のテスト：私はデザイナーコードに入りました（私はそれが厄介であることを知っています、私はただ必死です）。私は以下を追加しました：

    // zzz
    try
    {

        this.Adapter.Fill(dataTable);
    }
    catch ( global::System.Exception ex )
    {

    }

奇妙なことに、実行すると、以前と同じエラーが発生し、エラーメッセージに加えた変更が表示されません。

Line 13909:            }
Line 13910:            BPLL_Dataset.BLOG_TOPICSDataTable dataTable = new BPLL_Dataset.BLOG_TOPICSDataTable();
Line 13911:            this.Adapter.Fill(dataTable);
Line 13912:            return dataTable;
Line 13913:        }

私は困惑しています....多分それが私がトライキャッチで何もしていないのを見て、私のために最適化しているのでない限り。

別の補遺：デザイナーに追加したテストコードを無視しているのではないかと疑って、キャッチに何かを追加しました。同じエラーが発生し、このコードが表示されないように動作します。（まあ、わかりました。以前と同じようにブラウザに出力されるため、このコードは表示されません。）

    // zzz
    try
    {

        this.Adapter.Fill(dataTable);
    }
    catch ( global::System.Exception ex )
    {
        System.Web.HttpContext.Current.Response.Redirect("errorpage.aspx");
    }

元の投稿を作成したとき、私はすでに回避策を試みていました。うさぎの穴をどこまで下る余裕があるのか​​わかりません。たぶん、私は混乱全体をC＃に読み込んで、すべての結合を行い、自分自身をがらくたにします。私は最近習慣から抜け出したばかりなので、それをするのは本当に嫌いですが、神とマイクロソフトが意図した方法でツールを使用するために誠意を持って努力していると思います。ウィットエンドから、tff。

4

2 に答える 2

1

このクエリをC＃からどのように実行しているかは実際にはわかりませんが、SqlCommandのストレートテキストとして実行されているか、ORMによって実行されていると想定しています...このクエリをストアドとして記述しようとしましたか？手順とそれをそのように呼びますか？ストアドプロシージャは、サンプルデータを使用して単独でテストおよび実行する方が簡単です。

エラーがnull値に言及しているという事実を考えると、それがクエリに問題があり、コードの他の要素に問題がない場合は、次のフィールドのいずれかにある必要があると思います：BLOG_COMMENTS.bID BLOG_TOPICS .bIDBLOG_COMMENTS.Comment_Narrative

これらのフィールドのいずれかがNullableである場合は、比較または結合で使用する前に、それらに対してCOALESCEまたはISNULLを実行する必要があります。このような状況は、ほとんどのDBAがテーブルにnull許容列をできるだけ少なくすることを好む理由を説明しています。オーバーヘッドが発生し、エラーが発生しやすくなります。

それでも問題が解決しない場合は、NULL可能であり、このクエリによって返されるすべてのフィールドをCOALESCE/ISNULLします。方程式からすべてのnull値を取り出して、問題を解決します。次に、null値をnullにする必要がある場合は、原因を見つけるまで、一度に1つずつCOALESCE/ISNULLを削除します。

于 2012-02-29T13:20:26.933 に答える
0

私の問題は無知と少しの鈍さから来ました。フィールドがSQLテーブルのキーであるという理由だけで、それがテーブルアダプターのキーでなければならないことを意味することに気づきませんでした。SQLテーブルでキーフィールドが定義されていて、テーブルアダプタを作成する場合、アダプタの対応するフィールドもキーになります。私がしなければならなかったのは、テーブルアダプターのキーフィールドの設定を解除することだけで、それは機能しました。

解決：

  • アダプタのキーフィールドを選択します。
  • 右クリック
  • 「キーの削除」を選択します（フィールドは保持しますが、「キー」アイコンは削除します）

それでおしまい。

于 2012-03-16T15:15:50.670 に答える