DataTable：新しいセーフを挿入する前に古いDataRowsを削除しますか？

Question

私は型付きデータセットに多対多の関係テーブルを持っています。 私は新しい（前と同じかもしれない）を追加する前に、私は古い関係を削除しています。この方法は、フェイルセーフであるか、私は本当に（LINQを持つなど）が削除され、削除とだけは本当に新しく追加された1つを追加するために確保する必要がある場合場合

は今、私は疑問に思います。

SQL Serverでは、リレーションテーブルに対して定義された一意の制約です。この2つの外部キーは複合主キーです。

は、データアダプターは、R​​owStateが<>予測可能な変更なしかではないでDataRowを更新ためですか？ つまり、DataAdapter.Update(DataTable)は、キーがすでに存在するときに例外が発生する可能性がありますか？

これは、データモデルである：

これは、コードの一部（LbSymptomCodesがASP.Netリストボックスである）である：

Dim daTrelRmaSymptomCode As New ERPModel.dsRMATableAdapters.trelRMA_SymptomCodeTableAdapter 
For Each oldTrelRmaSymptomCodeRow As ERPModel.dsRMA.trelRMA_SymptomCodeRow In thisRMA.GettrelRMA_SymptomCodeRows 
    oldTrelRmaSymptomCodeRow.Delete() 
Next 
For Each item As ListItem In LbSymptomCodes.Items 
    If item.Selected Then 
     Dim newTrelRmaSymptomCodeRow As ERPModel.dsRMA.trelRMA_SymptomCodeRow = Services.dsRMA.trelRMA_SymptomCode.NewtrelRMA_SymptomCodeRow 
     newTrelRmaSymptomCodeRow.fiRMA = Services.IdRma 
     newTrelRmaSymptomCodeRow.fiSymptomCode = CInt(item.Value) 
     Services.dsRMA.trelRMA_SymptomCode.AddtrelRMA_SymptomCodeRow(newTrelRmaSymptomCodeRow) 
    End If 
Next 
daTrelRmaSymptomCode.Update(Services.dsRMA.trelRMA_SymptomCode) 

は、事前にありがとうございます。

Answer 1

私は、ADO.NETのDataAdapterが適切な順序で削除/挿入を実行するのに十分賢明だと思います。

しかし、正しい順序で更新が確実に行われるようにするには、Selectメソッドを使用して手動で行う必要があり、特定の行状態ごとにデータ行の配列を返します。その後、DBトランザクションは、次の順序削除、挿入、更新で実行する必要があります

DataTable tbl = ds.Tables["YourTable"]; 

// Process any Deleted rows first 
adapter.Update(tbl.Select(null, null, DataViewRowState.Deleted)); 

// Process any Updated/Modified rows 
adapter.Update(tbl.Select(null, null, DataViewRowState.ModifiedCurrent)); 

// Process the Inserts last 
adapter.Update(tbl.Select(null, null, DataViewRowState.Added)); 

Answer 2

DAわからなく、理論的に存在しないデータ行のアレイ上のUpdateメソッドを呼び出すことができます。 MSDNでの更新方法の正確な文言を探して

は

BLOCKQUOTEデータベースにDataTableのすべての変更を保存する 試みです​​。 （これは、テーブルに挿入された行を追加して、テーブルから削除された行を削除し、変更されたテーブル内の行を更新することを含む。） BLOCKQUOTE

を削除項目およびおそらくは再のソリューションに関しては同じアイテムを挿入すると、通常、DBに負荷がかかるため、これは避けるべきです。大量のアプリケーションでは、非常に高価なのでDBへの呼び出しを最小限に抑えるためにできることはすべて実行したいと考えています。どの行更新が擬似であるかを決定することからの計算時間は安い。