多用户访问和同步
由于 Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition) 支持多用户访问，因此在复制数据库时用户仍可继续使用此数据库。这会与在发布服务器上所做的更改发生冲突，称为本地数据冲突。在开发使用 SQL Server Compact Edition 的应用程序时必须考虑到这一点。
多用户访问的影响
在设计使用 SQL Server Compact Edition 的应用程序时，必须考虑多用户访问对数据库造成的影响。下表概述了 SQL Server Compact Edition 自带的某些常见功能以及与各功能相关的问题：
| 功能 | 问题 |
|---|---|
锁定 |
同步过程中，由于数据锁定的原因，在发布服务器上所做的更改可能不会应用于订阅服务器数据库。如果是在订阅服务器上进行数据更改且数据被长久锁定，同步可能会失败。 为彻底避免此类情况的发生，请为应用程序添加逻辑设置，禁止用户在同步过程中更改数据。 |
验证 |
如果要使用验证，而 SQL Server Compact Edition 数据库的行数在同步过程中发生更改，则验证将会失败。 为彻底避免此类情况的发生，请为应用程序添加逻辑设置，禁止用户在带验证的同步过程中更改数据。 |
重新初始化 |
重新初始化订阅的过程中，复制层将删除并重新创建所有已复制的用户和系统表。对于 SQL Server 订阅而言，同步启动后所做的任何更改在重新初始化时都将丢失。 为避免此数据丢失，请为应用程序添加逻辑设置，禁止用户在重新初始化过程中更改数据。 |
架构更改 |
所有 DDL 操作（架构更改）都必须对表有独占访问权限。如果其他进程也使用了此表，就将无法进行架构更改。 |
同步过程中进行更改 |
如果是在同步过程中进行数据更改，则此更改将在下一次同步时发出。如果同步会话引起本地冲突，即使项目是按列级别跟踪的，系统也会将行解析为行级别。 |
冲突检测与解决
在多用户环境下工作时，在同步过程中可能会发生导致冲突的更改。SQL Server Compact Edition 可检测客户端冲突，但不能解决冲突。相反，冲突信息将被传递给发布服务器，并在下一次同步时予以解决。
大多数冲突可在下一次同步时由发布服务器解决。但如果出现引用完整性 (R/I) 冲突，发布服务器就会要求设备进行自动重新同步。这种情况下，重新同步次数不会超过两次。
有关冲突检测和解决的详细信息，请参阅复制冲突检测和解决。
使用 SubscriberConflicts 属性
在同步过程中对本地数据库所做的更改会导致本地冲突。如果订阅服务器上无法应用发布服务器的行，则系统将认为发生订阅服务器冲突，这是将设置 SubscriberConflicts 属性。对于 SQL Server 订阅服务器而言，冲突将由订阅服务器解决。但是，SQL Server Compact Edition 没有协调器。所有冲突都必须由发布服务器解决。开发应用程序时，您可以将应用程序设计为在每次同步后检查 SubscriberConflicts 属性。如果将其设置为非零值，则数据必须进行重新同步后，发布服务器才能解决此冲突。
请参阅
概念
同步数据 (SQL Server Compact Edition)
同步数据同步
异步数据同步
复制冲突检测和解决