Dudas con aplicación access en red
En el taller que trabajo hay una pequeña aplicación hecha en access 2003, maneja varias tablas y en la que más registros tiene son unos 2.000 registros, la usamos unas 10 personas que acceden al mismo tiempo a la aplicación, esta en red de la siguiente forma:
Las bases en un archivo: taller_bases.mdb y por otro lado en otro archivo diferente están los formularios, consultas e informes: taller_aplica.mdb el cual vincula al archivo de las bases.
Los dos archivo (bases y aplicación) están situados en un PC que hace de servidor y luego en cada ordenador nuestro tenemos un acceso directo que abre el archivo taller_aplica.mdb
Es decir, los 10 empleados abrimos el mismo archivo: taller_aplica.mdb. Esta aplicación ya estaba hecha y lleva funcionando así cerca de un año y por lo que yo veo funciona bien.
Resulta que ahora por necesidades del taller he tenido que hacer otra pequeñísima aplicación, esta vez ya en access 2007 y he seguido la misma operativa: bases en un archivo y formularios, etc.. En otro distinto, pero ahora viene mi duda, buscando información he visto que quizás exista otra forma mejor de poner en red dichos archivos, esto es, en vez de situar los dos archivos en el PC-servidor y abrir todos los usuarios al mismo tiempo el mismo archivo que ejecuta los formularios, situar este archivo en cada PC de cada usuario, de forma que cada empleado ejecute su propio archivo de aplicación apuntando hacia el archivo de bases que ese si seguiría estando en la red.
Y aquí es donde no lo tengo muy claro, mi jefe dice que si esta funcionando de la primera forma que para qué voy a cambiarlo yo ahora.
Necesito ayuda y consejo, me gustaría saber pros y contras de hacerlo de una u otra forma, saber cómo maneja access los datos si abrimos todos el mismo archivo en la red o si cada usuario abre su propio archivo, si cambia la rapidez con que se ejecuten las consultas, si puede haber más probabilidad de cuelgues de una u otra forma, en fin razones de peso o comprobadas para decidir por una u otra forma de instalación.
1 Respuesta
Desde mi punto de vista estás utilizando de manera errónea lo que sería una división de la base de datos.
Me explico:
Tienes un primer sistema, que es tener la BD con tablas, formularios y demás en el servidor, y abrirlo directamente (por ejemplo poniendo un acceso directo en cada pc local de dicha BD del servidor). Esto puede ser útil si tienes pocos usuarios trabajando sobre la BD.
Tienes un segundo sistema, que consiste en dividir la BD. Dividir la BD consiste en dejar en el servidor una BD con las tablas (eso sería el back-end) y situar en cada pc local la BD con los formularios, informes, etc (eso serían los front-end). Estas BD's locales tendrían una vinculación a las tablas de la BD del servidor, pero no las tablas en sí.
Por lo que leo lo que tú tienes es el segundo sistema utilizado erróneamente: tu BD con sólo formularios, consultas, etc. debería estar en cada PC local.
Te pongo un ejemplo para que me entiendas.
Caso 1: tenemos la BD en el servidor con todo. Esfuerzo 100% para el servidor
¿Quién trabaja? -> El servidor con todo, y como tiene que "moverlo" todo pues... le cuesta.
Caso 2: tenemos la BD en el servidor con sólo las tablas, y la BD con los formularios, etc.
¿Quién trabaja? El servidor y los PC's locales. Esfuerzo repartido entre los ordenadores -> Y eso implica que la BD del servidor va más ligera y los PC's independientes también, porque sólo tienen que trabajar con su front-end
Caso 3 (tu caso): la BD front-end en el servidor y la BD back-end en el servidor.
¿Quién trabaja? El servidor. Y, aunque hayas dividido la BD, el esfuerzo sigue siguiendo un 100% para el servidor, lo que implica una disminución en el rendimiento.
Mi recomendación: dejar el back-end en el servidor y poner una copia de cada front-end en los PC's locales.
Si quieres algo más de información puedes echar un vistazo a este breve artículo, que creo que te ayudará a profundizar y entender mejor lo que te acabo de comentar: http://goo.gl/FNnC5
Espero haberte clarificado un poco tus dudas.
Magnífica explicación, te pido por favor a ver si me aclaras un poco más lo siguiente:
Crees que tendré algún problema de compatibilidad ya que mi aplicación hecha en 2007 que va a tener sus propias bases ademas va a tener también las otras bases vinculadas hechas con la versión del 2003, podría haber algún problema ?
Y también cuando se ejecutan las consultas, filtros, etc..., dónde se hace el movimiento de las tablas, en el servidor, en cada pc, me refiero a las cargas en memorias, etc..
Gracias de antemano.
Inicialmente no debería darte ningún problema. Como se dice por ahí, "lo mayor puede lo menor". En este caso la versión 2007 "lee" perfectamente lo que está en la versión "2003" (si fuera al revés te diría que ni siquiera podrías abrir la BD porque no te reconocería el formato de archivo).
Para que te hagas una idea, las BD's de ejemplo de la web (la mía, vamos) las preparo sobre un mdb (archivo de Access 2003) trabajándolas a través de un 2007 o 2010, y lo hago así para que, precisamente, quien tenga 2003 pueda abrirlas, dando por supuesto que 2007 y 2010 no tendrán ningún tipo de inconveniente (y, por ahora, nadie me ha dicho eso de "no puedo abrir tu BD de ejemplo").
Me extrañaría bastante que te diera problemas.
Sin embargo, como te veo tan "indeciso", lo que podrías hacer es lo siguiente:
- Te creas una copia de tu BD 2003
- Te creas una copia de tu BD 2007
- Rectificas las vinculaciones a las tablas, de manera que, en 2007 (la copia), apunten a la copia de 2003.
- Haces un testeo de funcionamiento, metiendo algunos registros inventados, intentando sacar algunos informes, etc. Como estarás operando sobre copias no pasa nada. Incluso lo puedes testear sobre un PC local para no tocar el servidor.
- Cierto es que un problema puede surgir en cualquier momento, pero si ya tu sistema ha superado esta fase de testeo las probabilidades de imprevistos en un funcionamiento "normal" de la aplicación se reducen bastante.
Si todo te funciona bien pues eliminas las copias, quedándote más tranquilo en cuanto a que el sistema funcionará perfecto.
Finalmente, y este es un consejo que siempre se da y hasta que no te pasa personalmente no se suele seguir, haz copia de seguridad de tus BD's. De hecho, y de nuevo para que te quedes más tranquilo, guarda una copia de seguridad de tus BD's "antes de implantar el nuevo sistema" y así sabes que, si llegara a pasar algo (repito: cosa bastante improbable), sólo habrías perdido algunos datos, pero no los datos de toda la vida de la aplicación (claro, si esto te pasa en los primeros días... si te pasa al año... uffff).
Pero bueno, lo anterior son consejos para ser ultra-prudente (lo de la copia periódica sí que es una necesidad, independientemente de qué versión de Access estés utilizando). Los problemas de compatibilidad entre versiones de Access que yo he visto por Internet son casos muy puntuales y bastante "raros".
Y creo que eso es todo. Para lo que necesites pues ya sabes ;-)
Otra vez.
Me he dado cuenta de que no te he respondido la segunda parte de tu consulta.
Te pongo un ejemplo (me gusta poner ejemplos, por si no se ha notado).
Imagínate la cocina de un restaurante. Tenemos un enorme refrigerador y dos o tres cocinas con sus respectivos fogones.
¿Qué hay en el refrigerador? Pues huevos.
El primer cocinero quiere hacer huevos fritos. Se va al refrigerador, saca los huevos que necesita y se pone a hacer los huevos fritos.
El segundo quiere hacer una tortilla a la francesa. Se va al refrigerador, saca los huevos y a cocinar la tortilla
El tercero simplemente quiere un huevo hervido. Pues... ya sabes: refrigerador -> huevos -> a hervir.
El cuarto cocinero viene de hacer la compra. Coge los huevos que ha comprado, abre el refrigerador y los guarda ahí.
Al acabar hay que recoger las sartenes, las ollas, limpiar los fogones, etc...
El refrigerador es la BD del servidor. Dentro tiene las tablas (huevos) con información. No está siempre abierto (porque nos entraría el calor y nos fastidiaría los alimentos). Su único trabajo es mantener la temperatura y "abrir la puerta" para enviar-recibir información.
Las cocinas son los PC's locales: todas parten de la misma información (huevos), pero uno necesita una consulta especial (huevos fritos), otro necesita otra consulta diferente (tortilla), otro sólo requiere de un informe (huevo hervido) y el último está dando de alta nuevos registros (la compra). Las sartenes, ollas, boles y similares (formularios) corren a cargo de las cocinas, no del refrigerador; las espumaderas, giradoras, tenedores... (macros, código VBA...) dependen de cada cocina, no del refrigerador. Y, evidentemente, hay que limpiar los fogones de cada cocina (el refrigerador ya lo limpiaremos, pero no cada vez que salga o entre un huevo de ahí!).
En definitiva, que quien realiza un "mayor esfuerzo" es el pc local, el servidor "sólo" proporciona los datos (y también los recibe), pero no mueve ni formularios, ni consultas, ni informes, etc.
Pues con esto creo que he dado respuesta a tu consulta... y espero que haya sido algo divertida ;)
Muchas gracias por las aclaraciones, al final con tanto ajetreo de cocina me entró hambre, je je je.
Por cierto, he estado ojeando algunos ejemplos que tienes en tu web y debo felicitarte por la forma de explicarlos, en cuento tenga algo de tiempo voy a empezar a realizar todos tus ejemplos, aunque estoy metido en pleno access te puedo asegurar que no tengo mucha experiencia y cada cosa que hago la saco a base de ejemplos, ayuda, probar y probar y probar...
Un saludo y gracias
