Sincronización y acceso multiusuario
Dado que Microsoft SQL Server Compact 3.5 admite el acceso de varios usuarios, un usuario puede continuar trabajando en la base de datos mientras esta se replica. Esto puede dar lugar a conflictos con los cambios procedentes del Publicador, a los que se denomina conflictos de datos locales, que es necesario tener en cuenta al desarrollar aplicaciones que utilicen SQL Server Compact 3.5. Además, algunos escenarios de la plataforma de 64 bits no admiten el acceso simultáneo a un archivo de base de datos con las versiones anteriores de SQL Server Compact. Para obtener información acerca de los componentes de 64 bits, vea Administrar las aplicaciones de base de datos de 64 bits.
Efectos del acceso multiusuario
Al diseñar una aplicación que utilice SQL Server Compact 3.5, debe tener en cuenta los efectos del acceso multiusuario en la base de datos. En la siguiente tabla se describen algunas de las características comunes incorporadas en SQL Server Compact 3.5, así como los problemas asociados con cada una de ellas.
Característica |
Problema |
|---|---|
Bloqueo |
Durante la sincronización, es posible que los cambios del Publicador no se apliquen a la base de datos de suscriptor a causa de los bloqueos de datos. Si se están realizando cambios en los datos del suscriptor y existen bloqueos de larga duración en los datos, pueden producirse errores en la sincronización. Para impedirlo, debe agregar a su aplicación lógica que impida que un usuario realice cambios en los datos durante la sincronización. |
Validación |
Si se emplea la validación y el número de filas de la base de datos de SQL Server Compact 3.5 cambia durante la sincronización, se producirá un error en la validación. Para impedirlo, debe agregar a su aplicación lógica que impida que un usuario realice cambios en los datos durante las sincronizaciones con validación. |
Reinicialización |
Durante la reinicialización de una suscripción, el nivel de replicación elimina y vuelve a crear todas las tablas de sistema y del usuario replicadas. Al igual que ocurre con las suscripciones de SQL Server, cualquier cambio que se realice una vez iniciada la sincronización se perderá al producirse la reinicialización. Para impedir esta pérdida de datos, debe agregar a su aplicación lógica que impida que un usuario realice cambios en los datos durante la reinicialización. |
Cambios en el esquema |
Todas las operaciones de DDL (cambios en el esquema) deben tener acceso exclusivo a la tabla. Si la tabla está siendo utilizada por otro proceso, se producirá un error al realizar un cambio en el esquema. |
Cambios durante la sincronización |
Si se produce un cambio en los datos durante la sincronización, el cambio se enviará durante la siguiente sincronización. Si una sesión de sincronización origina un conflicto local, la fila se resuelve a nivel de fila, incluso si el seguimiento del artículo se realiza a nivel de columna. |
Detección y resolución de conflictos
Si trabaja en un entorno multiusuario, durante las sincronizaciones pueden producirse cambios que causen conflictos. SQL Server Compact 3.5 detecta los conflictos del cliente pero no controla la resolución de conflictos. En vez de eso, la información del conflicto se envía al Publicador para que lo resuelva durante la siguiente sincronización.
La mayoría de los conflictos se resuelven en el Publicador en la siguiente sincronización. No obstante, si se produce un conflicto de integridad referencial (R/I), el Publicador solicitará una resincronización automática del dispositivo. Si se produce este comportamiento, no tendrán lugar más de dos resincronizaciones.
Para obtener más información acerca de la detección y resolución de conflictos, vea Detección y resolución de conflictos de replicación.
Usar la propiedad SubscriberConflicts
Los cambios realizados en la base de datos local durante la sincronización pueden causar un conflicto local. Si una fila del Publicador no puede aplicarse al Suscriptor, se considera un conflicto del Suscriptor y se establece la propiedad SubscriberConflicts. Con los Suscriptores de SQL Server, los conflictos se resuelven en el Suscriptor. No obstante, SQL Server Compact 3.5 no cuenta con un reconciliador. Todos los conflictos deben resolverse en el Publicador. Cuando se desarrolla una aplicación, ésta puede diseñarse de modo que examine la propiedad SubscriberConflicts tras cada sincronización. Si tiene un valor distinto de cero, es necesario resincronizar los datos para que el Publicador pueda resolver los conflictos.
Vea también
Otros recursos
Sincronizar datos (SQL Server Compact)
Sincronización de datos sincrónica