Información general sobre las aplicaciones conectadas ocasionalmente
Una aplicación conectada ocasionalmente es una aplicación que usa los datos de una base de datos remota pero puede que no siempre tenga acceso a esa base de datos. Las aplicaciones conectadas ocasionalmente también se usan cuando el acceso a la base de datos remota está continuamente disponible, pero puede no ser rentable realizar continuamente consultas sobre datos que se modifican en raras ocasiones, tales como una lista de estados o categorías de productos. En estas situaciones, las aplicaciones pueden usar los datos de una base de datos local ubicada en el cliente y que, periódicamente, sincroniza los datos con la base de datos remota ubicada en el servidor.
Es decir, si la aplicación requiere datos de una base de datos remota que no tienen porque obtenerse continuamente de la base de datos, se puede usar una caché de base de datos local para almacenar los datos en el equipo cliente, o directamente dentro de la aplicación. Por ejemplo, considere una aplicación de inventario que usa datos de varias tablas en una base de datos. El número de elementos disponibles para cualquier parte individual es una parte importante de datos que cambia continuamente, por lo que la aplicación, si es posible, siempre debería reflejar los valores actuales en la base de datos. Sin embargo, la aplicación también muestra una lista de compañías de distribución válidas que raramente cambia. Estas compañías de distribución válidas están almacenadas en la tabla de distribuidores y no tienen que recuperarse cada vez que se necesitan datos de la base de datos. Al almacenar esta tabla de distribuidores en una caché de base de datos local, se puede disminuir el número de ciclos de ida y vuelta innecesarios que la aplicación tiene que realizar a la base de datos remota. De esta forma, además de usar una caché de base de datos local para las aplicaciones que tienen una conectividad ocasional, considere la posibilidad de almacenar los datos que no cambian con frecuencia, o que cambian basándose en una programación conocida, en una caché de base de datos local.
Puede configurar el almacenamiento en caché para almacenar tablas individuales, conjuntos de tablas o registros concretos consultados en una tabla (por ejemplo, únicamente los clientes que tienen un determinado representante de ventas).
Microsoft Synchronization Services for ADO.NET (el espacio de nombres Microsoft.Synchronization.Data) facilita la sincronización de datos entre la base de datos cliente y la base de datos servidor. Puede configurar visualmente la sincronización en Visual Studio utilizando el cuadro de diálogo Configurar sincronización de datos o elAsistente para la configuración de orígenes de datos cuando crea un conjunto de datos con tipo. Para obtener más información, vea Cómo: Configurar la sincronización de datos en una aplicación y Tutorial: Crear una aplicación conectada ocasionalmente con el Asistente para la configuración de orígenes de datos.
Además, Visual Studio admite la característica de seguimiento de cambios de SQL Server 2008. Puede habilitar el seguimiento de cambios de SQL Server 2008 al configurar la sincronización desde el cuadro de diálogo Configurar sincronización de datos o el Asistente para la configuración de orígenes de datos. Para obtener más información, vea Cómo: Configurar la sincronización de datos para usar el seguimiento de cambios de SQL Server.
Limitación de la memoria caché de base de datos local en SQL Azure
Puede usar la memoria caché de base de datos local para sincronizar los datos encontrados en SQL Azure con una base de datos local de SQL Compact. Sin embargo, los servicios basados en nubes, como SQL Azure, heredan un entorno de varios inquilinos donde los clientes comparten el mismo hardware, pero los proveedores de datos existentes no están optimizados para este tipo de entornos. Para proteger a un cliente del impacto de la carga de trabajo iniciada por otro cliente, SQL Azure usa un mecanismo de limitación de peticiones que restringe la cantidad de recursos que se concede a una sola solicitud. En concreto, SQL Azure limita el tiempo durante el que una transacción puede ejecutase y el volumen que el registro puede crecer con una sola transacción.
Estos proveedores deben usarse en escenarios básicos y cuando las cantidades de datos son pequeñas. Si intenta sincronizar una gran cantidad de datos, puede producirse un error en la operación de sincronización debido a problemas con la limitación de solicitudes. Si se produce algún problema con la limitación de solicitudes, no hay forma de reducir el número de cambios para evitar errores de sincronización. Además, estos proveedores no resultan apropiados para escenarios más avanzados en los que se requiere una sincronización bidireccional.
Para obtener información detallada sobre los componentes optimizados para los escenarios relacionados con SQL Azure, vea https://go.microsoft.com/fwlink/?LinkId=180745.
API de Synchronization Services (Microsoft.Synchronization.Data)
Microsoft Synchronization Services for ADO.NET está diseñado para las aplicaciones conectadas ocasionalmente. Permite sincronizar los datos de orígenes dispares sobre arquitecturas con dos niveles, con n niveles y basadas en servicio. En vez de simplemente realizar la replicación de una base de datos y su esquema, la API de Synchronization Services proporciona un conjunto de componentes para sincronizar datos entre los servicios de datos y un almacén local. Las aplicaciones se usan cada vez más en clientes móviles, como equipos y dispositivos portátiles, que no tienen una conexión de red coherente o confiable a un servidor central. Es importante que estas aplicaciones funcionen con una copia local de datos en el cliente. Igualmente importante es el requisito para sincronizar la copia local de los datos con datos en un servidor central cuando está disponible una conexión de red. La API de Synchronization Services, que se modela después de las API de acceso a datos de ADO.NET, proporciona una manera intuitiva de sincronizar datos. Posibilita la creación de aplicaciones para entornos conectados ocasionalmente a una extensión lógica para crear aplicaciones de las que depende una conexión de red coherente.
Instalar la API y la documentación de servicios de sincronización
La API de Synchronization Services no forma parte de .NET Framework. Se instala como parte de la instalación de SQL Server Compact 3.5. (De forma predeterminada, SQL Server Compact 3.5 se instala al instalar Visual Studio.) De forma predeterminada, la documentación de Synchronization Services no se instala. Por consiguiente, sólo estará disponible si la Ayuda se configura para el uso en línea. Para instalar la documentación de Synchronization Services para su uso local, primero debe descargar la colección de Ayuda del sitio web Microsoft Synchronization Services for ADO.NET Books Online.
Incorporar la sincronización de datos en aplicaciones mediante Visual Studio
Para incorporar la sincronización de datos en una aplicación, Visual Studio proporciona una plantilla Caché de base de datos local. La Caché de base de datos local está disponible como una nueva plantilla de elemento de proyecto. (En el menú Proyecto, haga clic en Agregar nuevo elemento.) Para obtener más información, vea Cómo: Configurar la sincronización de datos en una aplicación.
Además de utilizar la plantilla Caché de base de datos local, también puede utilizar el Asistente para la configuración de orígenes de datos para configurar la sincronización. Durante la configuración de un conjunto de datos con tipo, seleccione la opción Habilitar almacenamiento en caché de la base de datos local en la página Elija los objetos de base de datos del asistente. Para obtener más información, vea Tutorial: Crear una aplicación conectada ocasionalmente con el Asistente para la configuración de orígenes de datos.
Al agregar una Caché de base de datos local, se abre el cuadro de diálogo Configurar sincronización de datos. Este cuadro de diálogo se usa para proporcionar información concreta sobre cliente y servidor, y configurar los componentes de sincronización necesarios. La caché de base de datos local usa una base de datos SQL Server Compact 3.5 en el cliente para almacenar datos localmente. Puede usar una base de datos SQL Server Compact 3.5 existente como la caché de base de datos local. Si todavía no tiene una base de datos local, puede usar el cuadro de diálogo Configurar sincronización de datos para crear una nueva base de datos local. Para crear una nueva base de datos de SQL Server Compact 3.5 local, puede establecer la Conexión de cliente (en el cuadro de diálogo Configurar sincronización de datos) para crear una nueva base de datos de SQL Server Compact 3.5 basada en las tablas seleccionadas en la Conexión del servidor.
Nota
El cuadro de diálogo Configurar sincronización de datos permite configurar Microsoft Synchronization Services for ADO.NET únicamente para los escenarios de descarga. Esto significa que después de configurar la sincronización de datos mediante este cuadro de diálogo, la llamada a Microsoft.Synchronization.Data.SyncAgent.Synchronize sólo actualizará la base de datos local con los cambios que se encuentren en la base de datos remota. Los cambios realizados en los datos de la base de datos local no se cargarán en la base de datos remota. Después de configurar la sincronización de datos mediante el cuadro de diálogo Configurar sincronización de datos, puede habilitar mediante programación las cargas (sincronización bidireccional) durante la sincronización. Para obtener más información, vea Cómo: Configurar una base de datos local y una base de datos remota para que exista sincronización bidireccional.
Configurar la base de datos remota para la sincronización
Para que la sincronización de datos funcione correctamente, hay algunas consideraciones adicionales que se necesitan en cada tabla de la base de datos remota con la que se desea realizar la sincronización. El cuadro de diálogo Configurar sincronización de datos crea scripts SQL que se ejecutarán contra la base de datos remota para crear los objetos necesarios (los objetos que se muestran en la tabla siguiente). Todos los scripts de SQL creados por el diseñador de sincronización se guardan en una carpeta SQLScripts del proyecto.
Nota
Los scripts SQL generados por el cuadro de diálogo Configurar sincronización de datos se ejecutan de forma predeterminada. Puede elegir si los scripts se generan y ejecutan estableciendo las opciones de Generaciones de scripts en el cuadro de diálogo Configurar tablas para usarlas sin conexión.
El comportamiento predeterminado del cuadro de diálogo Configurar sincronización de datos es ejecutar automáticamente los scripts y actualizar la base de datos remota cuando el cuadro de diálogo se cierra. Desactive la casilla Ejecutar scripts al cerrar este cuadro de diálogo, si no desea ejecutar automáticamente los scripts. Además, si la base de datos remota ya tiene las columnas de seguimiento necesarias, los desencadenadores y la tabla de elementos eliminados, no se generará ningún script. Es decir, si no se requiere ningún cambio en la base de datos remota, no se creará ningún script.
La tabla siguiente muestra los elementos necesarios en la base de datos remota y proporciona una explicación de cada uno de ellos:
Adiciones a cada tabla sincronizada en la base de datos remota |
Explicación |
|---|---|
Columna LastEditDate |
Esta columna debería ser DateTime o TimeStamp en cada tabla que se está sincronizando. Se compara con la columna LastEditDate en el cliente para identificar los registros modificados en el servidor desde la última llamada de sincronización. |
Columna CreationDate |
Esta columna debería ser DateTime o TimeStamp en cada tabla que se está sincronizando. Se compara con la columna CreationDate en el cliente para identificar los registros que se han agregado al servidor desde la última llamada de sincronización. |
tabla de elementos eliminados (TableName_Deleted) |
Los elementos se mueven a esta tabla cuando se eliminan de la tabla del servidor de bases de datos. Con ello, se identifican los registros eliminados del servidor desde la última llamada de sincronización. Cada tabla que está sincronizándose requiere una tabla de elementos eliminados para realizar el seguimiento de los registros eliminados de la tabla remota. |
DeletionTrigger (TableName_DeletionTrigger) |
Este desencadenador se ejecuta cada vez que se elimina un registro de la tabla de base de datos servidor. Los registros eliminados se mueven a la tabla de elementos eliminados. Se mueven a la tabla de elementos eliminada porque los registros en la base de datos cliente que no están en la base de datos servidor podrían tratarse como registros nuevos y se volverían a agregar al servidor. Synchronization Services comprueba la tabla de elementos eliminados para determinar si se debe eliminar un registro eliminado de la base de datos cliente en lugar de volver a agregarlo a la base de datos servidor. |
InsertTrigger (TableName_InsertTrigger) |
Este desencadenador rellena la columna CreationDate con la fecha y hora actual cuando se agregan los nuevos registros. |
UpdateTrigger (TableName_UpdateTrigger) |
Este desencadenador rellena la columna LastEditDate con la fecha y hora actual cuando se modifican los registros existentes. |
Iniciar el proceso de sincronización en una aplicación
Después de proporcionar la información necesaria en el cuadro de diálogo Configurar sincronización de datos, agregue el código a la aplicación para iniciar la sincronización. Es importante entender que la sincronización de datos actualiza la base de datos local, no la tabla del conjunto de datos o cualquier otro objeto en la aplicación. No olvide volver a cargar el origen de datos de la aplicación con los datos actualizados de la base de datos local. Por ejemplo, llame al método TableAdapter.Fill para cargar la tabla de datos del conjunto de datos con los datos actualizados de la base de datos local.
Vea también
Tareas
Cómo: Configurar la sincronización de datos en una aplicación
Tutorial: Crear una aplicación que se conecta ocasionalmente
Conceptos
SQL Server Compact 3.5 y Visual Studio