Visual Basic - Paso de datos de una base a otra con Visual Basic

Hola, soy nuevo en este foro y quisiera ver si me pueden ayudar con lo siguiente:
Si tengo una base de datos Access como principal con 7 bases de datos que alimentan a estas con tablas vinculadas en una computadora de mi trabajo y quiero pasar por medio de Visual basic 6, la primera vez todos los datos y luego solo los datos que se actualizan cada día a la computadora de mi casa, para seguir trabajando con los mismos y luego hacer lo contrario, es decir, pasar los datos actualizados de la computadora de mi casa a la de mi trabajo, ¿qué código necesitaría en Visual tomando en cuenta que la base de datos principal se alimenta de datos en tablas vinculadas?

Les agradezco de antemano por la ayuda

No creo que importe mucho cuantas DBs tenga y cuales sean principales y secundarias.

La cuestion es que tener 2 copias de las DB, una en el trabajo y otra en casa, y pretender tenerlas coordinadas a diario con un solo click es tarea dificil por no decir imposible.

Actualizar los datos tabla por tabla verificando qué datos son los que se han modificado sería muy costoso en todos los sentidos.

Lo único minimamente viable sería copiar los archivos de las DB de un lugar a otro, eliminando en cada ocasión las copias más antiguas.

Esto como poco es peligroso, porque es más que probable que en algúna ocasión actualicemos las DB a versiones anteriores a las existentes, con la consiguiente pérdida de datos.

Si se establece un riguroso protocolo para no confundir los datos actualizados con los antiguos, el código para copiar archivos sería sencillo.

Suerte.

Bueno, por lo menos lo llamas exposición, estamos progresando.

Pues yo tengo una libreta de apuntes, una agenda y una bitácora en mi escritorio. Definidas como bases de datos, tengo un total de tres, cuya combinación me hacen tener una base de datos de toda la información en papel que necesito. Como concepto de sistema de información, cualquier repositorio que guarde datos es una base de datos y la información recabada y obtenida, así como el proceso para que esto suceda, es lo que forma el sistema.
Todo esto para no entrar en el concepto de bases de datos distribuidas, que, en todo caso, es menos abstracto si se entiende lo que dije en el párrafo anterior.
Con respecto a la información distribuida, hay muchos ejemplos, desde el distribuidor de botanas que llega con su pda a las tiendas de conveniencia a levantar pedido y expedir recibos, hasta las empresas que tienen bases de datos en cada sucursal y una base de datos consolidadora en la central o matriz. Todas ellas requieren la sincronización de la información, así, se pueden tener bases de datos conformando toda la información para una sola. El hecho de que no lo haya expuesto de la mejor manera nuestro amigo, no significa que no se le pueda ofrecer una respuesta.
Alguna vez (año de 1999, ciudad de Monterrey en México) estuve trabajando para alguna empresa en la que se requería de enviar y recibir información desde la empresa hacia los clientes que le contrataban. La información se actualizaba (a ciertos niveles, según el caso) en ambos lados. La forma de sincronización era, por decir lo menos, compleja, toda vez que las vpn's no se conocían y aunque el frame relay era la panacea y a través de él podíamos distribuir sistemas en n capas, el costo era considerable. Así que cual fue la solución? Paquetes de información y una compleja pero ingeniosa forma de actualizar.
Se trataba de agregar al procedimiento de alta, baja y cambio en los regitros un trigger que almacenaba en tablas adicionales los cambios sufridos por los registros. Esto es, por ejemplo: para las bajas de una persona, incluir su id y en un campo adicional el status 'B' (char de tamaño 1), para las altas, todos los campos registrados y en el campo adicional un status 'A' y los cambios registraban el id, los campos modificados (y sólo ellos), además del status 'C'.
Luego, se generaban paquetes de información, que iban en formato mdb y lo que se hacía era cambiar los status por sus respectivas minúsculas. Así, los mdb sólo iban con los datos relevantes (todos los campos no utilizados se mandaban nulos), con los status en mayúsculas y cuando llegaban al otro lado (en un principio vía mail y luego automatizado por ftp), se cargaban las modificaciones (se daban de baja, cambiaban los campos y se daban de alta), en el paquete se cambiaban los status a minúsculas, se borraban todos los campos adicionales y se dejaban los id's, para enviar el paquete de regreso, en forma de acuse de recibo y este buscaba en las tablas adicionales por id y status y borraba los registros coincidentes.
Esto es, a grandes rasgos, lo que se hacía para sincronizar. Bueno, en realidad es lo básico, por que se hacían validaciones por fechas y otras cosas (como cambiarías un registro que ya no existe en la otra base de datos? por ejemplo), pero te puede dar un panorama de como es que puedes implementar lo que requieres.

Espero que te sirva.

Saludos.