默認(rèn)分類 2011-01-15 17:37:35 閱讀11 評(píng)論0 字號(hào)：大中小 訂閱
前段時(shí)間工作中的一個(gè)新需求，有機(jī)會(huì)用到了Linq to SQL。使用后的第一感覺，就是方便很多，也為整個(gè)項(xiàng)目節(jié)約了一大把的開發(fā)時(shí)間，甚至代碼量也少了很多。不過在程序的實(shí)際運(yùn)行中，始終會(huì)遇到一些莫名其妙的異常，最令人不解的，就是“System.Data.Linq.ChangeConflictException: Row not found or changed.” 。當(dāng)初憑自己和同事的判斷，可能是數(shù)據(jù)庫(kù)的數(shù)據(jù)異常所導(dǎo)致，后來發(fā)覺這個(gè)異常出現(xiàn)得越來越頻繁，于是上MSDN查了查，原來是Linq中一個(gè)常見的問題：更新沖突。
這個(gè)詞說起來比較玄乎，其實(shí)再平常不過了。下面可以通過一個(gè)簡(jiǎn)單的例子，來重現(xiàn)這個(gè)異常。
建立一個(gè)普通的測(cè)試表：LinqTest(如圖)
在測(cè)試表中，插入一條測(cè)試數(shù)據(jù)(如圖)
測(cè)試代碼如下：
1: namespace LinqTest
2: {3: class Program
4: {5: static void Main(string[] args)
6: {7: TestDataContext db = new TestDataContext();
8: db.Log = Console.Out;9: var result = from p in db.LinqTests
10: where p.ID == 1
11: select p; 12: var info = result.FirstOrDefault();13: if (info != null) //插入斷點(diǎn)
14: { 15: info.Age = 25; 16: db.SubmitChanges(); 17: } 18: Console.ReadLine(); 19: } 20: } 21: } 在測(cè)試代碼中，將DataContext的日志定向到Console的輸出部分，這樣方便我們觀察Linq實(shí)際執(zhí)行的SQL語(yǔ)句是什么。重現(xiàn)的時(shí)候，我們需要在注釋的地方，插入斷點(diǎn)進(jìn)行測(cè)試。對(duì)于示例中的代碼，在正常情況下，是不會(huì)有錯(cuò)誤的。執(zhí)行過后，我們可以在Console的輸出中，看到實(shí)際執(zhí)行的SQL語(yǔ)句(如圖) 
再進(jìn)行第二次調(diào)試，首先，恢復(fù)Age的數(shù)據(jù)到以前的樣子。下面我們運(yùn)行到斷點(diǎn)處，然后偷偷去SQL Server Management Studio中，手動(dòng)修改數(shù)據(jù)，將原始數(shù)據(jù)中的Age，由24，改為22。然后回到VS2008的IDE，按F5繼續(xù)運(yùn)行程序，這個(gè)時(shí)候，你會(huì)發(fā)現(xiàn)異常出現(xiàn)了(如圖) 
再回到Console的輸出，查看，執(zhí)行的SQL語(yǔ)句和剛才的一樣。這就是問題的所在，在正常運(yùn)行狀態(tài)下，Linq在運(yùn)行時(shí)，會(huì)把數(shù)據(jù)庫(kù)的數(shù)據(jù)緩存到實(shí)體對(duì)象中，這是一種理想化的情況，并且在更新時(shí)，Linq會(huì)默認(rèn)把除更新字段外的所有字段，作為Update語(yǔ)句中的Where條件。但是，如果此時(shí)有另外的程序，在訪問數(shù)據(jù)庫(kù)，并修改數(shù)據(jù)庫(kù)數(shù)據(jù)的時(shí)候，比如剛才把Age改為22。此時(shí)Linq緩存起來的數(shù)據(jù)和實(shí)際數(shù)據(jù)庫(kù)中的數(shù)據(jù)產(chǎn)生了不一致的情況。Linq此時(shí)仍然把被修改過的字段，作為Update的Where條件，但是數(shù)據(jù)庫(kù)中Age早就被我們改過了，不再是25，Where條件始終匹配不到原有的數(shù)據(jù)。這時(shí)，就會(huì)拋出所謂的：“System.Data.Linq.ChangeConflictException: Row not found or changed.”異常。
產(chǎn)生此異常，主要是Linq緩存數(shù)據(jù)和實(shí)際數(shù)據(jù)庫(kù)數(shù)據(jù)不一致的情況造成。解決次問題的情況，主要有幾種：
1.比較簡(jiǎn)單的方法，不使用Linq提供的SubmitChanges()方式提交更改，而直接執(zhí)行SQL語(yǔ)句，例如：
db.ExecuteCommand("Update [dbo].[LinqTest] SET Age=25 Where ID = @p0", 1);
這樣雖然比較方便，但是感覺又回到了直接寫SQL的時(shí)代，畢竟Linq to SQL的目的，就是為了讓我們看不見SQL，避免寫復(fù)雜的SQL語(yǔ)句，而直接操作實(shí)體對(duì)象，這樣也可以避免程序可讀性差、不便于維護(hù)。所以除非萬不得已，還是不太推薦使用此方法。
2.參考MSDN的資料，采用Linq提供的解決更新沖突的方法，在異常中捕獲沖突，然后手動(dòng)解決沖突：
程序代碼
1: try
2: { 3: db.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict); 4: }5: catch (System.Data.Linq.ChangeConflictException ex)
6: {7: foreach (System.Data.Linq.ObjectChangeConflict occ in db.ChangeConflicts)
8: {9: //以下是解決沖突的三種方法，選一種即可
10: //使用當(dāng)前數(shù)據(jù)庫(kù)中的值，覆蓋Linq緩存中實(shí)體對(duì)象的值
11: occ.Resolve(System.Data.Linq.RefreshMode.OverwriteCurrentValues); 12: //使用Linq緩存中實(shí)體對(duì)象的值，覆蓋當(dāng)前數(shù)據(jù)庫(kù)中的值
13: occ.Resolve(System.Data.Linq.RefreshMode.KeepCurrentValues); 14: //只更新實(shí)體對(duì)象中改變的字段的值，其他的保留不變
15: occ.Resolve(System.Data.Linq.RefreshMode.KeepChanges); 16: }17: //這個(gè)地方要注意，Catch方法中，我們前面只是指明了怎樣來解決沖突，這個(gè)地方還需要再次提交更新，這樣的話，值 //才會(huì)提交到數(shù)據(jù)庫(kù)。
18: db.SubmitChanges(); 19: }3. 這個(gè)方法也比較簡(jiǎn)單，也即MSDN中所說的Pessimistic Concurrency Control 。 我們可以來設(shè)定哪些字段需要放入Where條件，哪些字段不需要，這樣就可以控制更新時(shí)候的條件匹配尺度。具體做法，就是在Linq to SQL Designer中，把一些字段的UpdateCheck屬性設(shè)置為Never，這樣，這些字段在更新的時(shí)候，就不會(huì)再出現(xiàn)在Where條件中了。其實(shí)比較推薦的做法，就是在表中設(shè)立主鍵，因?yàn)楦碌臅r(shí)候，只要把主鍵作為Where條件，就可以單獨(dú)的確立一行數(shù)據(jù)了。把除主鍵外的字段屬性中UpdateCheck設(shè)置為Never即可。
聯(lián)系客服
