ms-access - tablas - como hacer una base de datos en access 2016

sincronización de bases de datos-MS Access (7)

Debería leer en Access Database Replication , ya que hay información disponible.

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

Utilice Jet and Replication Objects (JRO) si requiere control programático sobre el intercambio de datos y la 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 abra la base de datos. Para replicar una base de datos mediante programación, la base de datos debe estar cerrada.
Si su base de datos se creó con Microsoft Access 97 o una versión anterior, debe usar Objetos de acceso a datos (DAO) para replicarla y sincronizarla programáticamente.
Puede crear y mantener una base de datos replicada en versiones anteriores de Microsoft Access mediante el uso de 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 abra la base de datos.
Puede usar los siguientes métodos y propiedades para crear y mantener una base de datos replicada:
Método MakeReplica
Synchronize 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 registros en una réplica completa):
Propiedad de ReplicaFilter
Propiedad PartialReplica
Método PopulatePartial

Definitivamente debe leer la parte de Synchronizing Data de la documentación.

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

Necesito encontrar una manera automática de sincronizar los datos en una base de datos de acceso central.

Los datos en las computadoras portátiles solo se anexan 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?

Es posible usar la replicación de Jet incorporada en Access, pero te advertiré que es bastante escamosa. También estropeará su PK en cualquier tabla en la que lo haga, ya que selecciona enteros aleatorios para intentar evitar colisiones de teclas, por lo que puede terminar con -1243482392912 como su PK siguiente en un registro determinado. Es un PITA para escribir si está haciendo algún tipo de búsqueda en él (como una identificación de cliente, número de orden, etc.) No puede automatizar la sincronización de acceso (tal vez puede simular algo así usando VBA. , que solo se ejecutará cuando se abra la base de datos).

La forma en que recomendaría es usar SQL Server 2005/2008 en su base de datos "central" y usar SQL Server Express Editions como el back-end en sus bases de datos "remotas", luego usar tablas vinculadas en Access para conectarse a estas bases de datos SSEE y replicación para sincronizarlos. Configure la replicación de mezcla o la replicación de instantáneas con su base de datos "central" como publicador y sus bases de datos SSEE como suscriptores. A diferencia de la replicación de Access Jet, puede controlar la numeración PK, pero 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 automatizarlo utilizando 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 o cierra sesión) y la configura para que se sincroniza en un intervalo determinado, al 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 los usuarios se conectan a la red. Cosas muy interesantes

La replicación de acceso puede ser incómoda, y como solo requiere agregar consultas con alguna verificación, probablemente sea mejor escribir algo usted mismo. Si los datos recopilados por cada computadora portátil no se pueden superponer, esto puede no ser demasiado difícil.

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

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

Es posible usar la replicación de Jet incorporada en Access, pero te advertiré que es bastante escamosa.

Jet Replication no es flakey. Es perfectamente confiable cuando se usa correctamente, al igual que cualquier otra herramienta compleja. Es cierto que ciertas cosas que no causan problemas en una base de datos no replicada pueden provocar problemas cuando se replican, pero eso es razonable debido a la naturaleza de lo que implica la replicación de cualquier motor de base de datos.

También estropeará su PK en cualquier tabla en la que lo haga, ya que selecciona enteros aleatorios para intentar evitar colisiones de teclas, por lo que puede terminar con -1243482392912 como su PK siguiente en un registro determinado. Es un PITA para escribir si realiza algún tipo de búsqueda (como la identificación del cliente, el número de pedido, etc.)

Las PKs de Autonumáticos sustitutas nunca deberían estar expuestas a usuarios en primer lugar. Son números sin sentido usados para unir registros detrás de escena, y si los expone a usuarios ES UN ERROR EN SU DISEÑO DE APLICACIONES.

Si necesita números de secuencia, tendrá que hacer su propio y tratar el tema de cómo evitar colisiones entre sus réplicas. Pero ese 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 en el nivel del motor de base de datos y es una característica realmente agradable, pero tiene el costo de una sobrecarga administrativa mayor al mantener múltiples instancias de SQL Server (con todos los problemas de seguridad y rendimiento) eso implica). En Jet Replication, tendrías que hacer esto en código, pero ese no es un problema complicado.

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

Pero esto no es un defecto en la implementación de Replication de Jet: es un problema para cualquier escenario de replicación con una necesidad de números de secuencia significativos.

No puede automatizar la sincronización de acceso (puede simular algo similar utilizando VBA, pero aún así, solo se ejecutará cuando se abra la base de datos).

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

Una cita de la documentación de MS:

Usar objetos Jet y Replication

JRO realmente no es la mejor manera de administrar Jet Replication. Por un lado, tiene solo una función en ella que 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 (el JRO requiere una referencia, o puede usarse a través del enlace tardío), también podría agregar una dependencia en una biblioteca verdaderamente útil para controlar Jet Replication, y ese es el Sincronizador TSI , creado por Michael Kaplan, que una vez fue el experto más importante del mundo en Jet Replication (que desde entonces ha pasado a la internacionalización como su área de concentración). Le proporciona un control programático completo de casi todas las funciones de replicación que Jet expone, incluidas las sincronizaciones programadas, la iniciación de todo tipo de sincronización y el muy necesario comando MoveReplica (la única forma legal de mover o renombrar una réplica sin interrumpir la replicación).

JRO es uno de los feos hijastros de la campaña abortada ADO-Everywhere de Microsoft. Su objetivo es proporcionar funcionalidad específica de Jet para complementar lo que es compatible con ADO. Si no está utilizando ADO (y no debería estar en una aplicación de Access con un back-end de Jet), entonces realmente no desea usar JRO. Como dije anteriormente, agrega solo una función que 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 lo hubieran elegido.

Ahora que he eliminado las aserciones erróneas en las respuestas ofrecidas anteriormente, esta es mi recomendación:

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

Pero una advertencia: si el escenario de solo adición cambia en el futuro, se te aplicará una manguera y tendrás que empezar desde cero o escribir un montón de código para gestionar las eliminaciones y actualizaciones (esto no es fácil, confía en mí, 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 agregado sin ningún problema y luego manejará fácilmente la replicación completa de fusión en caso de que se convierta un requisito en el futuro.

Por último, un buen lugar para comenzar con Jet Replication es el Wiki de Jet Replication . Las páginas de Recursos, Mejores prácticas y Cosas que no se creen son probablemente los mejores lugares para comenzar.

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

Automatizar este tipo de comportamiento se llama replicación, y Access lo admite , aparentemente, pero nunca lo he visto implementado.

Como supongo, la mayoría de las veces el portátil no está conectado a la base de datos principal, de todos modos no es una buena idea (para 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 incrementalmente, por supuesto.

FWIW:

Autonumeros. Estoy de acuerdo con David: nunca deberían estar expuestos. Para eliminar esa tentación, uso un autonumber aleatorio.
Replicación. Hace unos años utilicé esto extensivamente, con sincronizaciones programadas y usando GUID como PK. Repetidamente descubrí que cualquier problema en la red corrompía las réplicas, con el resultado de que tuve que recuperar datos y volver a publicar réplicas. ¡Doloroso!

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 topamos, a nivel empresarial, fue administrar los CONFLICTOS . Si no se administran a tiempo, o hay demasiados, los usuarios se frustran y los datos no son confiables.

La replicación funcionó bien cuando nuestros sitios remotos no siempre estaban conectados a Internet. Esto les permitió trabajar con sus datos y sincronizarlos cuando pudieran. 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 ícono en su escritorio para evocar la sincronización.

El usuario tenía un botón separado para enviar / 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, hágamelo saber y puedo enviarle mi documentación.