多使用者存取及同步處理
因為 MicrosoftSQL Server Compact 3.5 支援多使用者存取，所以使用者可以在資料庫複寫時，繼續在資料庫上作業。這可能造成與發行者所做的變更的衝突，稱之為本機資料衝突，在使用 SQL Server Compact 3.5 開發應用程式時，必須將該因素考慮進去。此外，某些 64 位元平台案例並不支援使用舊版 SQL Server Compact 來同時存取資料庫檔案。如需有關 64 位元元件的資訊，請參閱＜管理 64 位元資料庫應用程式＞。
多使用者存取的影響
當設計使用 SQL Server Compact 3.5 的應用程式時，必須考慮多使用者存取資料庫的影響。下表摘要說明內建於 SQL Server Compact 3.5 的一些通用功能，以及每一個功能的相關問題。
功能 |
問題 |
|---|---|
鎖定 |
在同步處理期間，來自發行者的變更可能會因為資料鎖定，而不套用到訂閱者資料庫。如果資料變更正在訂閱者上執行，而且資料長期鎖定，同步處理作業可能會失敗。 若要完全避免這個問題，請在應用程式中加入邏輯，以防止使用者在同步處理期間變更資料。 |
驗證 |
如果使用驗證，而且 SQL Server Compact 3.5 資料庫中的資料列數目在同步處理期間變更，驗證將會失敗。 若要完全避免這個問題，請在應用程式中加入邏輯，以防止使用者在與驗證同步處理期間變更資料。 |
重新初始化 |
在訂閱的重新初始化期間，複寫層會刪除並重新建立所有複寫的使用者和系統資料表。至於 SQL Server 訂閱，當發生重新初始化時，任何在同步處理開始之後所做的變更將會遺失。 若要避免資料遺失，請在應用程式中加入邏輯，以防止使用者在重新初始化期間變更資料。 |
結構描述變更 |
所有的 DDL 作業 (結構描述變更) 必須能獨佔存取資料表。如果另一個程序正在使用資料表，結構描述變更將會失敗。 |
同步處理期間的變更 |
如果在同步處理期間發生資料變更，變更會在下次同步處理時傳送出去。如果同步處理工作階段造成本機衝突，即使發行項是追蹤的資料行層級，資料列會被解析為資料列層級。 |
衝突偵測與解析
當在多使用者環境中作業時，變更可能在同步處理期間發生，並造成衝突。SQL Server Compact 3.5 會偵測用戶端的衝突，但無法處理衝突解析。反而衝突資訊會傳送到發行者，以在下次同步處理時進行解析。
大部分衝突可以於下次同步處理期間，在發行者端進行解析。然而，如果發生「參考完整性」(R/I) 衝突，發行者將要求在裝置上自動重新同步處理。如果發生此行為，將不會發生兩次以上的重新同步處理。
如需衝突偵測與解析的詳細資訊，請參閱＜複寫衝突偵測與解決＞。
使用 SubscriberConflicts 屬性
在同步處理期間對本機資料庫所做的變更，可能會造成本機衝突。如果發行者的資料列無法在訂閱者端套用，會被視為訂閱者衝突，並且會設定 SubscriberConflicts 屬性。使用 SQL Server 訂閱者時，衝突會在訂閱者端進行解析。然而，SQL Server Compact 3.5 沒有 Reconciler。所有衝突必須在發行者端進行解析。當開發應用程式時，可將應用程式設計成在每次同步處理之後，檢視 SubscriberConflicts 屬性。如果設定為非零的值，資料必須重新同步處理，如此才能讓發行者解析衝突。