1

今日はこれを長時間見ていたので、愚かだったのかもしれません。しかし........

これを行う単純なストアド プロシージャがあります。

BEGIN
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

    DELETE FROM ProductLoading
END

テーブルProductLoadingは 3 つのフィールドで構成されていますが、いずれもキー フィールドではありません。これは、データが別のデータフィードからロードされているときに、しばらくの間データを保持する必要がある一時テーブルです。これは、製品の削除を確認するために行います。

このコードを実行すると、別のテーブルからもすべて削除されますProducts3。この行をコメントアウトしても、そうではありません。

キーとインデックスの専門家ではありませんが、基本的な理解はしています。しかし、両方のテーブルを見ても、依存関係は見当たりません。Products3さらに、実行計画を実行すると、テーブルが参照されません。

本当にこれにこだわった。私が見落としていることについて誰か教えてください。

4

4 に答える 4

1

どのような不具合が発生したかは不明です。

しかし、頭を悩ませた後、基本的にダミーの挿入ステートメントをストアドプロシージャに追加して再コンパイルしました。

奇妙なことに、delete ステートメントは Products3 テーブルまでフィルタリングされませんでした。

次に、このダミーの挿入ステートメントを削除しましたが、さらに奇妙なことに、ストアド プロシージャは引き続き機能しました。

今までと違うのは、テーブルが間違ったスキーマで作成されたときだけでした。私はすぐにこれに気付き、正しいスキーマでテーブルを再作成し、間違って作成されたテーブルを削除しました。この時点ではデータが存在しなかったため、この間に何かが破損したかどうかはわかりません. 方法がわかりませんが、1 と 0 が足し合わないことがあります。

そのため、解決策はありません。liの1つにすぎません

于 2012-06-10T11:59:15.007 に答える
1

Cascading Reference Integrity Constraintsのように聞こえます。の 3 つのフィールドの 1 つがProductLoadingキーではないことは確かですか?

于 2012-06-08T19:32:23.883 に答える
0

ProductLoading の読み込みには、カスケード削除が有効になっている別のテーブルへの外部キーである主キーが含まれている必要があります。

ここに画像の説明を入力

于 2012-06-08T19:30:14.763 に答える
0

理論的には、テーブル ProductLoading に削除のトリガーを設定できますか?

于 2012-06-08T19:33:15.210 に答える