sincronización de bases de datos - MS Access

Question

Tengo un problema en este momento en el que se usan múltiples (mismo esquema) bases de datos de acceso 2003 en las computadoras portátiles.

Necesito encontrar una forma automatizada de sincronizar los datos en una base de datos de acceso central.

Los datos en las computadoras portátiles solo se agregan para que las operaciones de actualización / eliminación no sean un problema.

¿Qué herramientas me permitirán hacer esto fácilmente? ¿Qué factores afectarán la decisión sobre la mejor herramienta o solución?

Answer 1

Es posible usar la replicación Jet incorporada en Access, pero te advierto, es bastante escamosa. También arruinará tu PK en las tablas en las que lo hagas, ya que elige enteros con signo aleatorio para intentar evitar colisiones de teclas, por lo que podrías terminar con -1243482392912 como tu siguiente PK en un registro determinado. Es un PITA para escribir si está realizando cualquier tipo de búsqueda en él (como el ID de un cliente, el número de pedido, etc.) No puede automatizar la sincronización de acceso (tal vez pueda simular algo así utilizando VBA. Pero aún así , solo se ejecutará cuando se abra la base de datos).

La forma en que recomendaría es usar SQL Server 2005/2008 en su " central " base de datos y use SQL Server Express Editions como back-end en su "control remoto" bases de datos, luego use las tablas vinculadas en Access para conectarse a estas bases de datos SSEE y la replicación para sincronizarlas. Configure replicación de mezcla o replicación de instantáneas con su " central " base de datos como editor y sus bases de datos SSEE como suscriptores. A diferencia de la replicación de Access Jet, puede controlar la numeración PK, pero para usted, esto no será un problema ya que sus suscriptores no impulsarán cambios.

Además de la escalabilidad que traería el servidor SQL, también puede automatizar esto usando el administrador de sincronización de Windows (si tiene carpetas sincronizadas, esa es la pequeña caja molesta que aparece y las sincroniza cuando inicia / cierra sesión), y configúrelo para que se sincronice en un intervalo determinado, en el inicio, apagado o en un momento del día, y / o cuando la computadora está inactiva, o solo se sincroniza a pedido. Incluso si Access no se ejecuta durante un mes, su conjunto de datos se puede actualizar cada vez que sus usuarios se conectan a la red. Cosas muy chulas.

Answer 2

La replicación de acceso puede ser incómoda, y como solo necesita agregar consultas con algunas comprobaciones, probablemente sería mejor escribir algo usted mismo. Si los datos recopilados por cada computadora portátil no pueden superponerse, esto puede no ser demasiado difícil.

Tendrá que considerar las claves primarias. Puede ser mejor incorporar el nombre del usuario o del equipo portátil en la clave para garantizar que los registros se relacionen correctamente.

Answer 3

Las respuestas en este hilo están llenas de información errónea sobre Jet Replication de personas que obviamente no lo han usado y simplemente están repitiendo cosas que han escuchado o atribuyen problemas a Jet Replication que en realidad reflejan errores de diseño de la aplicación.

  

Es posible utilizar el Jet   replicación incorporada en Access, pero yo   le advertirá, es bastante inusual.

La replicación de Jet no es flakey. Es perfectamente confiable cuando se usa correctamente, como cualquier otra herramienta compleja. Es cierto que ciertas cosas que no causan problemas en una base de datos no replicada pueden generar problemas cuando se replican, pero eso es lógico debido a la naturaleza de lo que implica la replicación por cualquier motor de base de datos.

  

También arruinará tu PK   cualquier mesa en la que lo hagas porque   escoge enteros con signo aleatorio para probar   y evitar las colisiones clave, por lo que podría   terminar con -1243482392912 como su   siguiente PK en un registro dado. Eso es un   PITA para escribir si estás haciendo algo   tipo de búsqueda en él (como un cliente   ID, número de pedido, etc.)

Las PK sustitutivas de Autonumber nunca deben exponerse a los usuarios en primer lugar. Son números sin sentido utilizados para unir registros detrás de escena, y si los está exponiendo a los usuarios, ES UN ERROR EN EL DISEÑO DE SU APLICACIÓN.

Si necesita números de secuencia, tendrá que rodar los suyos y tratar el problema de cómo evitar colisiones entre sus réplicas. Pero eso es un problema para la replicación en cualquier motor de base de datos. SQL Server ofrece la capacidad de asignar bloques de números de secuencia para réplicas individuales a nivel de motor de base de datos y esa es una característica realmente agradable, pero tiene el costo de una mayor sobrecarga administrativa por mantener múltiples instancias de SQL Server (con todos los problemas de seguridad y rendimiento que conlleva). En Jet Replication, tendrías que hacer esto en código, pero eso no es un problema complicado.

Otra alternativa sería usar un PK compuesto, donde una columna indica la réplica de origen.

Pero esto no es un error en la implementación de la replicación de Jet, es un problema para cualquier escenario de replicación que requiera números de secuencia significativos.

  

No puedes automatizar el acceso   sincronización (tal vez puedas falsificar   algo así usando VBA. pero   aún así, eso solo se ejecutará cuando el   Se abre la base de datos).

Esto es evidentemente falso. Si instala el sincronizador Jet, puede programar sincronizaciones (sincronizaciones directas, indirectas o de Internet). Incluso sin él, podría programar un VBScript para que se ejecute periódicamente y hacer la sincronización. Esos son solo dos métodos para lograr la sincronización automática de Jet sin necesidad de abrir su aplicación Access.

Una cita de la documentación de MS:

  

Usar Jet y objetos de replicación

JRO realmente no es la mejor manera de administrar Jet Replication. Por un lado, solo tiene una función que el propio DAO carece, es decir, la capacidad de iniciar una sincronización indirecta en el código. Pero si va a agregar una dependencia a su aplicación (JRO requiere una referencia, o puede usarse mediante un enlace tardío), también podría agregar una dependencia en una biblioteca realmente útil para controlar Jet Replication, y esa es la TSI Synchronizer , creado por Michael Kaplan, una vez que el experto más destacado del mundo Jet Replication (que desde entonces ha pasado a la internacionalización como su área de concentración). Le brinda control programático completo de casi todas las funciones de replicación que expone Jet, incluida la programación de sincronizaciones, el inicio de todo tipo de sincronización y el muy necesario comando MoveReplica (la única forma legal de mover o cambiar el nombre de una réplica sin romper la replicación).

JRO es uno de los hijastros de la campaña ADO-Everywhere abortada de Microsoft. Su propósito es proporcionar una funcionalidad específica de Jet para complementar lo que es compatible con ADO. Si no está usando ADO (y no debería estar en una aplicación de Access con un back-end de Jet), entonces realmente no quiere usar JRO. Como dije anteriormente, agrega solo una función que ya no está disponible en DAO (es decir, iniciar una sincronización indirecta). No puedo evitar pensar que Microsoft estaba siendo rencoroso al crear una biblioteca independiente para la funcionalidad específica de Jet y luego omitir a propósito todas las funciones increíblemente útiles que podrían haber respaldado si hubieran elegido.

Ahora que eliminé las afirmaciones erróneas en las respuestas ofrecidas anteriormente, esta es mi recomendación:

Debido a que tiene una infraestructura solo para anexos, haga lo que @Remou ha recomendado y configure algo para enviar manualmente los nuevos registros a donde sea que deban ir. Y tiene razón en que todavía tiene que lidiar con el problema de PK, tal como lo haría si usara la replicación Jet. Esto se debe a que es necesario por el requisito de agregar nuevos registros en varias ubicaciones, y es común a todas las aplicaciones de replicación / sincronización.

Pero una advertencia: si el escenario de solo agregar cambia en el futuro, se le aplicará una manguera y tendrá que comenzar desde cero o escribir una gran cantidad de código meticuloso para administrar las eliminaciones y actualizaciones (esto no es fácil - confíe yo lo he hecho!). Una ventaja de solo usar Jet Replication (aunque es más valioso para sincronizaciones bidireccionales, es decir, ediciones en múltiples ubicaciones) es que manejará el escenario de solo agregar sin ningún problema, y ??luego manejará fácilmente la replicación de fusión completa en caso de que se convierta un requisito en el futuro.

Por último, un buen lugar para comenzar con la replicación de Jet es el Wiki de replicación de Jet . Las páginas de Recursos, Mejores prácticas y Cosas para no creer son probablemente los mejores lugares para comenzar.

Answer 4

Debería leer en Acceso Base de datos Replication , ya que hay cierta información disponible.

Pero creo que para que funcione correctamente con su aplicación, deberá implementar una solución personalizada utilizando métodos y propiedades disponibles para ese fin.

  

Use Jet y Replication Objects (JRO) si necesita un control programático sobre el intercambio de datos e información de diseño entre los miembros del conjunto de réplicas en las bases de datos de Microsoft Access (solo archivos .mdb). Por ejemplo, puede usar JRO para escribir un procedimiento que sincronice automáticamente la réplica de un usuario con el resto del conjunto cuando el usuario abre la base de datos. Para replicar una base de datos programáticamente, la base de datos debe estar cerrada.

     

Si su base de datos se creó con Microsoft Access 97 o anterior, debe usar Data Access Objects (DAO) para replicarla y sincronizarla mediante programación.

     

Puede crear y mantener una base de datos replicada en versiones anteriores de Microsoft Access utilizando métodos y propiedades DAO. Use DAO si necesita control programático sobre el intercambio de datos y la información de diseño entre los miembros del conjunto de réplicas. Por ejemplo, puede usar DAO para escribir un procedimiento que sincronice automáticamente la réplica de un usuario con el resto del conjunto cuando el usuario abre la base de datos.

     

Puede usar los siguientes métodos y propiedades para crear y mantener una base de datos replicada:

     

  
• MakeReplica método
  
• Sincronizar método
  
• propiedad ConflictTable
  
• propiedad DesignMasterID
  Propiedad
• KeepLocal
  Propiedad
• Replicable
  Propiedad
• ReplicaID
  Propiedad
• ReplicationConflictFunction
  

     

Microsoft Jet proporciona estos métodos y propiedades adicionales para crear y mantener réplicas parciales (réplicas que contienen un subconjunto de los registros en una réplica completa):

     

  
• propiedad ReplicaFilter
  Propiedad
• PartialReplica
  
• Método PopulatePartial
  

Definitivamente debería leer la parte Sincronización de datos de la documentación .

Answer 5

Utilicé la replicación en a00 durante años, hasta que me obligaron a actualizar a a07 (cuando desapareció). El problema más problemático con el que nos encontramos, a nivel empresarial, era la gestión de los CONFLICTOS . Si no se gestiona a tiempo, o hay demasiados, los usuarios se frustran y los datos se vuelven poco confiables.

La replicación funcionó bien cuando nuestros sitios remotos no siempre estaban conectados a Internet. Esto les permitió trabajar con sus datos y sincronizarse cuando pudieron. Al menos dos veces al día.

Instalamos una base de datos separada en las computadoras remotas que administraron la sincronización, por lo que el usuario solo tuvo que hacer clic en un icono en su escritorio para evocar la sincronización.

El usuario tenía un botón separado para empujar / extraer alimentaciones de un archivo FTP designado que se actualizaría desde los sistemas Legacy.

Este proceso funcionó bastante bien, ya que teníamos 30 de estos '' nodos '' Trabajando en todo el país, gestionando sus datos y actualizando a los servidores FTP.

Si está considerando seriamente este camino, avíseme y puedo enviarle mi documentación.

Answer 6

Puede escribir su propio software de sincronización que se conecta a la computadora portátil, selecciona el diff de su db y lo inserta en el maestro. Depende de su esquema de datos qué tan fácil será esta operación. (si tiene muchas tablas con FK ... deberá hacerlo de manera inteligente). Creo que será más eficiente si lo escribes tú mismo.

La automatización de este tipo de comportamiento se llama replicación, y Accesss Admite eso aparentemente, pero nunca lo he visto implementado.

Como supongo que la mayoría de las veces la computadora portátil no está conectada a la base de datos principal, no es una buena idea de todos modos (replicar datos).

si busca una herramienta de terceros para hacerlo, busque algo que pueda hacer fácilmente la diferencia entre las tablas antes de copiar, y puede hacerlo de forma incremental, por supuesto.

Answer 7

FWIW:

1. Autonumbers. Estoy de acuerdo con David: nunca deberían estar expuestos. Para eliminar esa tentación, utilizo un número automático aleatorio.
2. Replicación. Lo utilicé ampliamente algunos años atrás, con sincronizaciones programadas y con GUID como PK. Repetidamente encontré que cualquier problema en la red dañó las réplicas, con el resultado de que tuve que salvar datos y volver a emitir réplicas. ¡Doloroso!