RDA 衝突偵測和報告
在發送作業期間，對於無法在執行 SQL Server 之電腦上更新的資料列，Microsoft SQL Server Compact 3.5 中的遠端資料存取 (RDA) 僅提供有限的衝突報告機制。
重要
在 RDA 中，衝突資料列嚴格定義為︰在從 SQL Server Compact 3.5 發送到 SQL Server 資料表時，因為錯誤造成插入、更新或刪除作業失敗。不同使用者對資料所做的變更，如果不造成錯誤，便不視為衝突。
雖然 RDA 不提供如複寫一般的特定解析程式，SQL Server Compact 3.5 仍提供擷取所有衝突資料列的錯誤資料表。您可以將錯誤資料表指定為 Pull 方法的一部分。在發送期間發生的錯誤，會記錄在此錯誤資料表中。藉由使用錯誤資料表，您可以開發應用程式來管理衝突偵測和報告。
對發送到伺服器之 SQL Server Compact 3.5 資料庫所做的變更，會依照接收的次序套用。SQL Server 資料表會更新，以反映最後使用者所做的變更。
在 RDA 中，當資料列不能從 SQL Server Compact 3.5 發送到 SQL Server 時，即存在衝突。RDA 只支援資料列層級追蹤。因此，某些資料列成功，某些失敗，端視在 Push 方法選取哪些選項而定。若要追蹤 RDA 中的衝突，請在 Pull 方法中指定 TRACKINGON 或 TRACKINGON_INDEXES。
當使用 RDA 追蹤的資料表時，藉由修正篩選資料表，以及在傳播資料時使用穩定的網路連接，即可避免衝突和錯誤。
RDA 衝突發生的原因
由於下列因素，資料列的變更無法在伺服器套用︰
RDA 追蹤裝置上追蹤資料表已變更的每一資料列的插入、更新及刪除作業。因此，如果插入到用戶端的資料列，具有與已插入到伺服器相同資料表中之資料列相同的主索引鍵值時，用戶端的發送作業將會因錯誤而失敗，因為插入作業已經發生。
如果資料沒有針對每一個使用者正確分割，當一個使用者嘗試更新某資料列時，另一個使用者可以刪除同一個資料列。
如果先前的發送被中斷，資料列也會無法發送到伺服器，而造成錯誤。例如，使用者開始發送資料到伺服器 (包括插入)，在發送期間，網路連接中斷。用戶端顯示因網路連接中斷而發送失敗的訊息。然而，變更實際上已經套用到伺服器。當用戶端重新取得網路連接，使用者第二次嘗試發送相同的資料時，某些資料列無法套用，因為那些資料列已在先前的發送作業中被插入。在此狀況下，應用程式應該忽略錯誤資料表中，因第二次發送之重複主索引鍵而失敗的所有錯誤。
錯誤資料表
藉由將錯誤連同失敗的資料列一併傳回並儲存到 SQL Server Compact 3.5 資料庫的錯誤資料表中，RDA 追蹤資料衝突，以及因錯誤而無法套用到伺服器的資料列。您會在 Pull 方法中定義此資料表。稍後，如果在發送作業中發生任何錯誤，便儲存到錯誤資料表。
使用 Push 方法時，如果資料列因重複主索引鍵這類的錯誤而無法套用到伺服器，可參考原來在 Pull 方法中定義的錯誤資料表名稱，解析此資料列。Pull 方法的 ErrorTableName 屬性，指定儲存發送錯誤應使用的資料表名稱。錯誤資料表會立即建立，但是剛開始沒有任何的資料列。只有在 TRACKINGON 或 TRACKINGON_INDEXES 以 Pull 方法指定時，ErrorTableName 才會被指定。
在 Push 方法期間，如果因無法套用資料列而發生錯誤，SQL Server Compact 3.5 會針對每一個錯誤，在資料表中插入一筆記錄。另外三個資料行連同基底資料表的所有資料行會一起加入，以識別錯誤發生的原因和時間點。s_ErrorDate 資料行指定錯誤發生的日期和時間。s_OLEDBErrorNumber 資料行指定將資料列套用到伺服器時，發生錯誤的 HResult。s_OLEDBErrorString 資料行是錯誤的字串描述。當 Push 方法結束，並且嘗試將資料列套用到伺服器而發生錯誤時，警告 (SSCE_WRN_RDAERRORROWSRETURNED, value 28800) 就會報告給應用程式，應用程式會檢查錯誤資料表以判定錯誤發生的原因。
維護錯誤資料表
如果關聯的 RDA 追蹤資料表已卸除，錯誤資料表會自動刪除，即使資料列仍存在於此錯誤資料表中也是如此。開發者必須解決被視為衝突的資料列，因為這些資料列無法套用在伺服器。
可能需要重新整理裝置上的資料，才能正確解析在原本將資料發送到伺服器作業時所發生的錯誤。建議您將資料快取到錯誤資料表中，以免在卸除追蹤資料表時遺失。或者，您可以將重新整理的資料提取到與原始追蹤資料表名稱不同的資料表中。
資料發送後解析錯誤
連同失敗之資料列一起儲存在錯誤資料表中的錯誤，會描述資料列為何無法在伺服器插入、更新或刪除。視錯誤而定，有的就一定要瞭解伺服器資料的目前狀態。應用程式必須設計為能處理此狀況，因為刪除追蹤資料表即會刪除錯誤資料表。
錯誤和非批次交易
在非批次交易 (使用 Push 方法時的 BATCHINGOFF 選項) 期間，在資料列層級偵測到衝突。衝突資料列會傳回應用程式，並儲存在指定的錯誤資料表中。例如，如果應用程式嘗試發送資料列到無效的 SQL Server，該資料列會傳回到應用程式，並連同指出衝突的錯誤訊息儲存在錯誤資料表中。
當衝突的資料列傳回到錯誤資料表時，資料列會從原始資料表中移除。因為資料表已不在原始狀態，要解析已發生的衝突會更困難一些。您必須將應用程式設計為可讓使用者修正衝突資料。若要這樣做，可能必須從伺服器重新提取資料表，以正確解析狀況。
卸除裝置上的資料表會造成錯誤資料表也被卸除。您必須將錯誤資料表中的資料列快取到暫存位置，或是從伺服器提取資料到不同的資料表。由於錯誤的資料列已經從 SQL Server Compact 3.5 資料庫的資料表中移出，使用正確的伺服器資料再一次重新整理資料表是很重要的。如果失敗的資料列已更新過，該資料列必須再一次更新，才能在後續的發送作業中順利完成。如果資料列已經更新，但伺服器上的資料列已經刪除，則必須在資料表中再次加入資料列，然後再發送一次，才能順利插入。
錯誤和批次交易
RDA 也支援批次發送 (使用 Push 方法時的 BATCHINGON 選項)，這需要所有的資料列順利完成整個發送作業。如果有一個資料列失敗，整個發送交易即失敗，沒有資料會更新。衝突資料列會複製到錯誤資料表。這是慣用的選項，因為它會啟用較容易的機制解析衝突。與非批次發送不同的是，原始的 Microsoft Windows CE 資料庫仍完整保留。您必須將應用程式設計為允許使用者修正衝突資料，並將其合併回原始的 Windows CE 資料庫。由於原始的資料列仍完整保留，有的錯誤可能不需要立即重新提取伺服器資料，以判斷資料列的正確解析方法。例如，如果資料列因完整性違規而失敗，便可更新裝置上的資料列，並叫用 Push 方法，嘗試發送資料到伺服器。此選項也提供較乾淨的維護，因為錯誤資料表會在複製衝突資料列之前自動清理。只有上次發送作業時發生的衝突存在於資料表中。