1

実際のプロジェクトで使用する前に、Linq-to-SQLの理解を深めるために取り組んでいるので、ちょっとしたサイドプロジェクトで遊んでいます。DataContext.SubmitChanges（）を介して更新しようとしているテーブルがありますが、主キーの制約が原因で失敗しています。

テーブル自体を制御することはできません（実際のID列を追加することはできません）。そのため、代わりに、3つの列を複合キーとして使用するようにLinqエンティティを変更しました。キーデータが更新セットとテーブル内の既存のデータの両方で一意であるにもかかわらず、挿入はまだ失敗しています。その理由を知りたいと思います。Linqがこれらの値を非一意として扱うように強制する何が欠けていますか？

更新の問題自体を解決しようとしているのではないことに注意してください。私の状況では、DataContext.ExecuteCommand（）も同様に機能すると判断しました。Linq（または私のデータ）の理解が間違っているところを探そうとしています。

テーブル構造は次のようになります。OPRID（char（30））DATE（DateTime）PROJECT_ID（char（15））HOURS（decimal）

最後の3列は複雑なキーです。

カンマ区切りのサンプルデータを次に示します：cschlege、2009-1-5、10100、0.8 cschlege、2009-1-5、10088、1.1 cschlege、2009-1-5、10099、0.8 cschlege、2009-1-5、 10088、1.2

SubmitChanges（）は、これらの行の最後で一貫して失敗しますが、DATE、PROJECT_ID、HOURSのキーを指定すると、これらの行は一意である必要があります。HOURS列に重複がある3行目では失敗しませんが、重複するPROJECT_IDに達した場合にのみ失敗します。ただし、複合キーからPROJECT_IDを削除すると、3行目で挿入が失敗します。

LINQがこれらの行を一意のキーとして扱わないのはなぜですか？

4

2 に答える 2

1

あなたの説明を考えると、HOURS（10進数）が問題だと思います...何らかの方法で異なる精度でマッピングする必要があります。

1.2 が 1 に丸められる場合、次の問題があります。

cschlege、2009-1-5、10088、1 ( 2)

cschlege、2009-1-5、10088、1 ( 4)

あなたが言ったように、プロジェクト ID を削除すると、3 行目で失敗します。

cschlege、2009-1-5、10100、0 ( 1 )

cschlege、2009-1-5、10099、0 ( 3 )

データベースの最後の行だけを挿入して、それが1.2であることを確認できますか?

于 2009-01-15T19:18:06.317 に答える
0

ああ。答えは、私はバッキングストアのルールに十分な注意を払っていないということです。実際に失敗している別のインデックスがあります。

于 2009-01-15T19:09:14.960 に答える