Como realizar actualización bd desde otra en access
Tengo un base de datos diseñada en access y lo que quiero es mandarla a varios compañeros y que la vayan cubriendo todas las semanas luego me la dejan en una nube y lo que pretendo es actualizar mi base de datos con la de mis compañeros es decir anexar todos los datos que ellos meten a mi bd sin duplicar registros es decir todas las semanas ejecutar un comando que todo lo nuevo que tengan lo copie en mi bd.
No se si eso es posible o cual seria la manera adecuada para hacerlo.
2 Respuestas
En Access 2003 tienes la posibilidad de crear bases replicadas. A partir de Access 2007 ya no hay esa posibilidad.
Una manera de hacer lo que pides es crearte un campo adicional en cada tabla que quieras conjuntar que te sirva de identificador único no sólo del registro sino de la BD que lo ha generado.
Para hacer eso tienes dos posibilidades:
1.- Crearte ese identificador como clave combinada.
2.- Utilizar el tipo de datos Id de réplica.
En el primer caso la clave combinada queda un poco a tu libre albedrío, según lo que consideres más adecuado para tu sistemática de trabajo. Por ejemplo, y suponiendo que tienes un campo Id autonumérico, tu clave combinada podría estar formada por ese Id más el usuario (Id+Environ("username"). O también podría estar creada por el id+fecha+hhnnss (por ejemplo te quedaría 123-110615-091024).
Para utilizar el id de réplica simplemente tienes que crearte un campo autonumérico y en sus propiedades, en lugar de "entero largo", seleccionas "id de réplica". Te generará un número aleatorio de 16 bits con un formato peculiar.
Todo lo anterior si estamos hablando de una BD "simple" (por llamarlo de alguna manera). Si tus tablas tienen relaciones entre ellas, y dependen de un Id, deberás también tener en cuenta que la relación no puede basarse en un id normal (porque al trabajar con diferentes bases de datos el valor de ese id ya no es único para el conjunto), sino que deberás basarlo en ese nuevo id único para TODAS las Bd's que estés manejando. Y eso significa, según cómo lo tengas, reestructurar la totalidad de tu aplicación :-(
Para actualizar tus datos "sólo" tendrás que hacer una inserción de datos en tus tablas, dando por supuesto que ese nuevo id es "sin duplicados". Cuando hagas ese insert into (si lo haces con una consulta normal) te meterá los datos nuevos y te dará el típico mensaje de "no se han podido insertar x registros por infracción de clave" (o algo similar), que en tu caso es correcto porque no quieres tocar los que ya tienes.
Sin embargo, el proceso anterior no actualiza modificaciones. Para ello deberías, en cada tabla, poner un campo auxiliar tipo sí/no para que se marque cada vez que se modifica un registro. Entonces el proceso sería:
- Actualizo en mi DB máster los registros modificados (según el Id único para todas las bases de datos)
- Una vez hecho el proceso anterior, marco en la BD de la que estoy extrayendo los datos el campo sí/no, que antes estaba marcado como True, como False.
Y si tienes registros que se hayan borrado... ufff. Pues te recomiendo que trabajes en todas las tablas no con el borrado físico, sino con el borrado lógico, con lo que el proceso sería muy parecido al de la modificación de datos.
Como ves, lo que pides es bastante trabajoso y, según cómo lo tengas, complicado. Quizá, si no tienes problemas de conectividad, la solución ideal sería tener los datos como back en un servidor en la nube, tipo Azure o myPhp, y los front en Access, y te olvidas de "procesos manuales de réplica". Pero eso ya es otra historia.
Un saludo,
Lo que me refería es que ahora mismo esta hecho sobre un excel y mis compañeros suben el excel al onedrive y desde el excel "maestro" se adjunta los datos de los otros.
Entonces la idea para tema de "facilitar trabajo" pensé en la creación de una base de datos, esta misma consta de varias tablas y todas ellas relacionadas por un código que un autonumérico manual creado por código, dicha tabla tiene 4 campos (código, servicio, fecha, estado) y el formulario principal esta basado sobre esa tabla con varios subformualrios relacionados cada uno sobre su tabla pero todos relacionados con el código dicho (como tu ejemplo de Formulario por fichas).
Lo que me refiero de importar es que cada uno lleva una asamblea y la forma de coordinarlo todo para eso seria esta pero cada semana puede variar el estado de alguna tabla ya que se va rellenando por momentos, con eso me refería a actualizar ciertos campos. Pongo como ejemplo el tuyo mencionado antes y hoy doy de alta el socio, la semana que viene le añado los datos, y la siguiente una actividad etc...
¿Crees qué esta estructura que tiene la bd seria complicada para lo que pretendo? Que una vez a la semana cada uno de ellos mande su base de datos al onedrive y yo ejecute la importación de sus tablas a la mía, es decir la mía tendría los datos de todas.
Un saludo
Me remito un poco a lo que te explicaba antes: necesitas un identificador único no sólo de registro, sino también de tabla, y necesitas indicar de alguna manera que ese registro se ha modificado. Y si además me dices que hay relaciones, pues peor me lo pones.
Se me ocurre una estructura que quizá no sea la más cómoda pero, por lo que me comentas que necesitas, podría funcionar (ojo, hay que probarlo, porque digo "podría"), siempre y cuando las relaciones fueran creadas por identificadores únicos de registro (sin duplicados). Si hay duplicados no sirve.
En las tablas de las BD's que repartes que tengan esa tabla, pero identificada por nombre. Por ejemplo, si la tabla se llama TDatos, pues llamarlas TDatos1 en la base que utiliza Fulanito, TDatos2 en la base que utiliza Menganito, y así sucesivamente. Y esas tablas todas con un campo que se rellene automáticamente con un valor predeterminado, como por ejemplo NumBase (el que se rellene con el 1 se correspondería con TDatos1, el 2 con TDatos2, etc.). Ese campo no debe aparecer en ningún formulario, por supuesto.
Y en tu base máster no tener una sola tabla, sino tenerlas todas. Haces la importación de TDatos1 de Fulanito sobre TDatos1 en el master, TDatos2 de Menganito sobre TDatos2 en el máster, etc.
A continuación, en tu base máster, te creas una consulta de unión sobre todas las tablas TDatosX y basas el formulario máster no sobre una tabla, sino sobre esa consulta de unión. Así tendrías todos los datos "individualizando" sus orígenes.
Si tú trabajas sobre el máster también deberías tener una tabla sólo para trabajar (TDatosZ), dado que la consulta es para la extracción de información.
Ahora bien, si quieres modificar datos tendrás que hacerlo sobre la tabla origen (de ahí la utilidad del campo NumBase), pero cuando vuelvas a realizar la importación de datos tus cambios, realizados en el máster, se van a machacar. Si tú no tocas esa información, o si se modifica directamente por el responsable en su propia BD, esto no pasaría.
Lo cierto es que pueden hacerse pruebas, pero de una manera u otra el sistema es más un apaño que un sistema y debes asumir la posibilidad de que puedan perderse datos.
¡Gracias! Voy a intentar lo que me comentas modificando mi ejemplo para ello
La solución que te comenta Sveinbjorn es quizás la más sencilla y fácil de aplicar. Yo no la había mencionado porque había dado por supuesto que ya la habías pensado pero que por la estructura del Excel (o por alguno de los "perros" que comenta Sveinbjorn) no se podía aplicar a tu Bd.
Si no es así pues he supuesto demasiado :-)
Perros no, "peros". Bendito corrector ortográfico... je, je...
Buenas noches neckkito la verdad que lo propone Sveinbjorn era la primera opción pero como es un excel tiene pocos datos de hay que lo hiciera mucho más completo con varias tablas relacionadas como comente
Buenos días quiero retomar el tema este y para ello como identificador que me comentabas he pensado en un id alfanumérico como el de tu ejemplo por poner un ejemplo de como estructuraría la bd seria algo así:
TServicios:(id, fecha, lugar, solicitante...) para Oviedo el id seria OVD0001 y para Gijón GI0001, Avilés AV0001 y así...
TTraslados(id(autonumerico), idServicio, hora, nombre,.....)
¿En este caso el id debería de ser propio también?
Las tablas que tendrían relaciones serían 4 que dependerían de TServicios y serian:
Traslados, atenciones, voluntarios mediante el id alfanumérico.
¿Esta estructura es válida? O es mejor para cada id de las tablas crear un identificador único.
Un saludo
Ciertamente no soy capaz de contestarte qué es lo mejor dado que no veo clara ni la sistemática de trabajo, ni cómo se van a introducir los datos (¿Excel?), ni cómo se van a incorporar los datos...
Lo que debes tener claro es que si estableces las relaciones entre las tablas con ese identificador alfanumérico que propones, y los datos se deben introducir primero en un Excel, tienes una probabilidad muy elevada de que se cometan errores precisamente al no trabajar directamente con Access. Access es un gestor de bases relacional y, lógicamente, tiene herramientas para controlar que las relaciones sean correctas; Excel no lo es.
Saludos. Neckkito
Buenos días Neckkito.
No no el excel quedaría suprimido.
Se trabajaría directamente con access. Los campos básicos estarían en una tabla la cual generaría el alfanumérico personalizado para cada base de datos(OVD001, GI0001, etc...) y las relaciones estarían establecidas igual para todas las bases. mediante el alfanumérico:
Tabla1(id(alfanumerico), lugar, solicitante,....)
Tabla2(id, idTabla1(alfanumerico), Nombre,....)Tabla3(id, idTabla1(alfanumerico),....)Sería necesario que el id de las Tablas 2 y 3 fuera propio no se repitiera o podría ser autonumerico, pongo un ejemplo de importacion de estas tablas 2 y 3 ya que de la tabla1 no habria problema.1) 1;OVD0001,Oviedo,kike2)1;GI0001,Gijon,kikeSi yo estos dos registros me los importo a la tabla2 de la bd madre al tener el mismo id sería posible?La idea es la misma bd (alfanumerico personalizado) para varios sitios y desde una bd madre importar los registro de las anteriores de todas las tablas para trabajar o consultarlos.Un saludo
Creo que lo que te he respondido aquí es aplicable a lo que pides: http://goo.gl/rgma15
Saludos. Neckkito
Por aportar otra idea:
Si tienes los archivos de excel que repartes y semanalmente te los devuelven (y suponiendo que no les cambies los nombres),¿? ¿Por qué no vinculas esos archivos de excel a tu access?.
Así podrás trabajar con los datos de excel desde tu access como si los tuvieras en tablas de access, y si necesitas tener un resumen, puedes hacer una consulta de union como te indicaba Neckkito.
Ah, me olvidaba decirte: los excel nuevos que te vayan remitiendo, los pones en la misma carpeta que los primeros que vincules (sobreescribiendolos).
Obviamente este método que te comento sólo te servirá si los excel son "acumulativos", es decir, no se borran cada semana y se empieza de nuevo.
Buenas noches Sveinbjorn, y ante todo muchísimas gracias a los dos por darme soluciones como siempre.
También pensé en hacerlo como me comentas, crear una tabla en access con los campos de las columnas del excel, e importar los datos de cada archivo de excel a ella, ya que ellos lo que hacen cuando lo ponen en el onedrive es reemplazar el existente y quedan siempre con el mismo nombre.
¿Seria posible como me dices que cuando de importar datos de todos los archivos de excel que haya me importe las filas nuevas y donde se hayan producido cambios? O tendría que tener una tabla por cada excel que necesito.
La idea de hacerlo como le explicaba a neckkito era para aportar más datos ya que lo tenia en access para cuando necesitara totales o resúmenes me supondría menor trabajo.
Un saludos
Yo no te digo importar el excel, sino vincularlo directamente. Con eso consigues una "tabla" en access con los datos que tengas en las columnas de excel, y los puedes manejar casi como si los tuvieras en access (puedes hacer consultas, informes..., pero no editarlos)
Para ello en la opción de importar, escoge la opcion que dice "vincular al origen de datos creando una tabla vinculada"
Ok y cuando se elige esta opción de vincular al origen cuando ellos sobrescriben el excel los datos que haya en la bd los sobreescribe o añade los nuevos sin eliminar los otros.
Los cambios que se hagan en el excel se reflejan en el access, es decir, en access verás lo que haya en el excel.