RE:Paso de datos de una base a otra con Visual Bas
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.