.net sql-server microsoft-sync-framework disconnected occasionallyconnected

.net - Sync Framework con SQL DB''s: Primeros pasos



sql-server microsoft-sync-framework (9)

¿Ha intentado filtrar sus artículos de replicación de mezcla en el nivel de fila todavía? Esto reduciría su tamaño de fila 14k en algo manejable.

Tengo una aplicación que utiliza SQL Enterprise para almacenar todos los datos en 4 bases de datos diferentes. Necesitaba desarrollar la capacidad de trabajar "sin conexión" para mis usuarios. Logré esto a través de Merge Replication de Merge Replication en instalaciones locales de SQL Express para todos. Esto "funciona", pero se siente como el enfoque de martillo.

Por ejemplo, estoy replicando las 14000 personas en cada base de datos cuando un usuario individual solo puede NUNCA interactuar con un 100 o más. Eso ni siquiera cuenta el hecho de que NUNCA interactuarían con más de 5 ish entre las conexiones a la base de datos central.

Lo que estoy buscando son sugerencias, punteros y, quizás, un buen tutorial sobre Sync Framework 2 (con bases de datos). Cuentas de primera mano sobre lo que funcionó para usted y por qué también sería bienvenido. Todavía tengo que encontrar un tutorial claro y conciso (por no mencionar el actual) para trabajar con Sync Framework .

Mis detalles son MS SQL Server 2005 o 2008, cualquier versión. Cualquier versión .Net (3.5 o 4). La capa de datos actual es todo LinqToSQL . No hay ningún Sprocs actualmente en uso.

Mis pensamientos, hasta el momento, son solo para sincronizar la carga de trabajo asignada a cada trabajador y los datos asociados. Lo ideal sería ir directamente a un formato de "Registro de entrada / Salida" en el que seleccionen a los miembros a los que planean visitar y luego se sincronizan los datos necesarios.

Como beneficio adicional, ¿podría alguien decirme a qué se refiere esto? Me encuentro "ocasionalmente conectado" todo el tiempo, pero eso parece inexacto. ¿Sería más exacto llamarlos "Ocasionalmente DIS-Conectados", pensamientos?


Después de muchos días de problemas con el marco de sincronización, estoy considerando deshacerme de él y simplemente escribir algunos servicios y códigos simples de WCF. Mis requisitos son bastante simples, sincronización unidireccional de SQL2008 a SQL CE en dispositivos móviles. Desde mi experiencia, es muy difícil de personalizar (solo sincronizar algunos campos, etc.) y es extremadamente lento e ineficiente. Creo que Microsoft necesita hacer un poco más de trabajo para facilitar su uso.

Aclamaciones

marca


Esto se llama esencialmente computación distribuida .

En cualquiera de los sistemas en los que he trabajado, normalmente he usado una arquitectura N-Tier para permitir la conexión ocasional de un programa cliente al servidor de base de datos en el back-end para las operaciones de CRUD. Cualquier trabajo que haga el cliente se considera sin conexión, ya que no interactúan con el servidor hasta que guardan sus cambios.

Usando este tipo de enfoque, debería poder hacer una aplicación que les permita conectarse por un momento para obtener algunos datos, realizar un trabajo en los datos y luego propagar cualquier cambio (CRUD) al servidor (base de datos).

Tendría que decir que el uso de la replicación de mezcla con las instalaciones de Local Sql Express es sin duda un enfoque de martillo. No se sienta tan mal por eso, todos lo hacemos de vez en cuando: P.

EDITAR

No he usado Sync Framework, pero me parece bien. Echa un vistazo a Sync Framework Developer Center para obtener más información sobre él.


Hemos estado usando Sync framework en algunos de nuestros proyectos (uno con servidor SQL, uno con PGsql), así que puedo decir que funciona bastante bien.

Echa un vistazo a esta aplicación tutorial para tener una idea de lo que puedes hacer.

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=4835

Esto le mostrará cómo sincronizar datos entre varias bases de datos de servidores SQL. También puede personalizar los procedimientos almacenados de ''incrementos'' para tomar parámetros personalizados y filtrar datos según estos parámetros (por ejemplo, las personas que el cliente-usuario planea visitar).

También le sugeriré que use un reflector para descompilar el código del marco de sincronización en caso de que vea errores extraños; a veces no es posible averiguar dónde está el error hasta que vea la excepción atrapada en el código del marco. ¡Redgate funciona perfectamente para mí!

¡Dejame saber si necesitas mas ayuda!


La pregunta es si su aplicación necesita ejecutarse en el dispositivo con datos desconectados almacenados localmente, o puede crear una versión móvil de un front-end web porque se supone que siempre deben estar conectados a un servidor cuando se trabaja con los datos ?

Los proyectos en los que trabajé (hace mucho tiempo) usaban el marco compacto y activesync con un back-end de Access o SQL Server porque era demasiado caro tener cada dispositivo conectado todo el tiempo, como un teléfono. Llevaron el dispositivo al campo, necesitaban acceder a los datos de la base de datos desconectada, hicieron sus modificaciones y sincronizaron cuando regresaron a la oficina.

Si eso es lo que estás haciendo, puedes usar su ID de dispositivo para identificar qué casos / filas necesita cada dispositivo, pero si estás pensando en desarrollar una solución de sincronización personalizada, creo que estás luchando en la batalla equivocada. Eso ya se ha hecho. Use una solución de sincronización probada, limitaciones y todo, y céntrese en los criterios que puede usar para limitar los datos sincronizados.


Me parece que Microsoft Sync puede ser una buena opción para usted. Hay una descripción general de la sincronización de bases de datos aquí, http://msdn.microsoft.com/en-us/sync/bb887608.aspx . Eche un vistazo y vea si satisface sus necesidades. Suena como la solución perfecta para su problema.


Parece que necesita tener más control sobre las opciones de fusión de datos. Con este requisito puedo ver que hay 2 tipos de datos; Datos que pertenecen a un Miembro (el caso pertenece a un miembro) y Datos compartidos (Referencia, Datos maestros).

Tendría una mezcla de estas técnicas en este caso para hacer las cosas semi rápidas.

Por ejemplo, los cambios de datos maestros y de referencia no son tan frecuentes. Por lo tanto, no necesitamos sincronizar muy a menudo, sino que debemos tener el control sobre los cambios y debemos / debemos hacerlo en una ubicación central. En este caso, haría los cambios en mi base de datos central y utilizaría el enfoque Sledge Hammer.

Para los datos transaccionales, suponiendo que una vez sea direccional, en este caso el miembro solo puede cambiar los casos / filas que le pertenecen, se puede implementar de muchas maneras.

Como se mencionó anteriormente, puede usar Sync Framework Developer Center o ActiveSync.

Dado que los umbrales no son tan estrictos como en PDA o Palmtops, también podemos probar un enfoque manual ya que tenemos computadoras portátiles. Implementar una rutina de funcionalidad / proceso para conectar y enviar datos que se crean, actualizan y eliminan (en este caso, debemos mantener una marca en el nivel de db) utilizando BulkCopy Operations, el enfoque más común en este escenario (es necesario proporcionar un botón). para que los miembros hagan clic e invocen, o un servicio para sondear y verificar la conectividad e iniciar la rutina de sincronización automáticamente).

/ KP


Tengo un par de sugerencias y sugerencias que pueden o no ser obvias / útiles.

Para mí, esto suena como un problema que se puede dividir en 3 aspectos separados:

Proceso de sincronización

  • Definitivamente, debe asegurarse de que todas las filas tengan algún tipo de columna "last_update" para que su proceso de sincronización pueda determinar de manera eficiente y confiable qué datos ya están actualizados; de esa manera, puede ser mucho más agresivo con la cantidad de registros que estas sincronizando
  • Evitaría tener procesos complejos de sincronización y simplemente utilizar el enfoque de fuerza bruta siempre que sea posible. Para mí, 14.000 registros no me parecen tantos; con las optimizaciones puede encontrar que es posible sincronizar todos los cambios realizados entre las conexiones en un tiempo razonable. Si no, entonces probablemente sería bastante liberal con respecto a lo que sincronizas para evitar que los usuarios trabajen con datos desactualizados sin darse cuenta.

Empujando cambios realizados en modo offline

Si es posible, es probable que simplemente rechace los cambios en el modo fuera de línea; eso no es posible, entonces debería considerar impulsar los cambios como un proceso separado (y probablemente bastante complejo) por derecho propio.

Sin saber más sobre la aplicación, es difícil hacer buenas sugerencias, ya que el proceso de sincronización depende en gran medida del negocio, sin embargo, algunas cosas a considerar son:

  • ¿Deberían los usuarios poder bloquear (o retirar) un elemento para evitar que otras personas lo cambien mientras trabajan fuera de línea?
  • ¿Debería ser anulable la cerradura?
  • Si se invalida un bloqueo, ¿qué debería suceder cuando alguien intenta guardar cambios (un proceso de combinación parece una opción sensata)?
  • ¿Debería alguien poder editar un elemento que no haya desprotegido?

Si decide implementar un complejo proceso de cambios fuera de línea, es posible que desee echar un vistazo al flujo de trabajo utilizado en el VCS distribuido común como inspiración.

Cambiar el almacén de datos fuera de línea

Es posible que el uso de SQL Compact o SQLite como su almacén de datos local sea una solución más elegante (sin duda facilitaría el proceso de instalación). Si está usando LINQ, entonces es probable que prefiera SQL Compact, ya que definitivamente tiene LINQ. Soporte de SQL

Me concentraría primero en los dos anteriores, ya que este cambio ofrece la menor cantidad en términos de mejoras para el usuario final y es probablemente el trabajo más exitoso. Los dos anteriores son completamente alcanzables sin dejar de usar SQL Server Express como el almacén de datos local.