Ejemplo código BD Access varios usuarios
¿Me pueden decir por favor cómo puedo hacer que formularios independientes ataquen a las tablas, en mi caso vinculadas? Se trataría de tener la bbdd dividida, una parte con las tablas en una carpeta de red y otra con los formularios.
Algo como lo que dice Pere Miralles en el artículo que enlazo,
Gracias
Saludos,
2 Respuestas
Gracias Enrique por responder pero no entiendo lo que dice del formulario Modal. ¿A qué se refiere? Yo lo que preguntaba era cómo trabajar con formularios independientes ya que parece ser que es la opción óptima para trabajar con access en un entorno multiusuario.
Lo que dice después, es precisamente lo que preguntaba :) cómo lo puedo hacer, un ejemplito, una ayuda
Una opción:
Utilizar las tabla vinculadas, pero utilizarla en modo lectura, cuando se desee modificar o crear un registro se abre el formulario en modo MODAL (en la llamada) en modo lectura/escritura.
Como la apertura en modo MODAL impedirá acceder a otra parte de la aplicación, evitaran esos molestos olvidos.
Si se tiene experiencia con VBA y los recordset, a esos formularios se les puede eliminar el origen de datos -seran formularios independientes- y recrear procesos para cargar los datos (cuadros de texto, cuadros de lista...), si se generan cambios o nuevos registros, habrá que actualizarlos/insertarlos en la tabla a la que pertenecen, según se trate de una modificación o uno nuevo.
Los formularios tienen dos propiedades que si se utilizan pueden solucionar problemas.
Modal es una de esas propiedades, la otra es la de poder ser 'emergentes' (siempre visibles).
La propiedad modal lo que hace es que mientras el formulario este abierto y sea el activo, no se puede acceder a cualquier otro objeto de la base.
La propiedad modal se puede aplicar en modo diseño (tomara el control cuando pueda) o se le puede aplicar (a cualquier formulario) en la propia sentencia que lo abre, (en este caso toma el control inmediatamente, lo que este haciendo lo deja en pausa y lo finalizara cuando se cierre el formulario abierto como modal.
...
Para hacer un ejemplo se tiene que conocer el entorno de red, como se trabaja con los datos (si los crean unos operarios y otros los complementan o si el que accede a la base puede hacer todo lo que quiera ...).
El numero de usuarios también influye y algo que es indispensable: tener dominio sobre los recordset y el lenguaje SQL (hay que imitar lo que Access hace por defecto).
Hay alternativas que pueden hacer la funcionalidad que se pretende:
Tener (en local) una copia del conjunto de datos a manipular como tabla temporal (al resto de datos se accede en modo solo lectura) y finalizada la tarea (sea manipulación o creación) se actualizan contra los datos originales, en principio es método mas sencillo (solo le ganaría utilizar DLookup).
Muchas gracias Enrique por toda la información que me facilita. Si me he enterado bien, ¿propone 2 alternativas?:
Una:
- Trabajar con tablas vinculadas en modo lectura ¿eso se hace desde la hoja de propiedad del formulario en el tipo de recordset, verdad?
Duda: Aunque solo sea de lectura, cuando un usuario entre en un registro, ¿esto no hará como dicen que hace Access que cuando un usuario entra en un registro, llama a todo el bloque de datos que conlleva, origen de muchos conflictos?
- Y cuando se quiera modificar los datos, abrir un formulario modal independiente y luego cargar los datos actualizados en la tabla, por ejemplo con un update,, esto creo que sí lo podría hacer, también más o menos me defiendo con los recordset. Además, el código no tendría que conectarse a la otra base de datos porque las tablas las tengo vinculadas, que eso ya me parece más complicado para mí, sino que puedo utilizar el mismo lenguaje que he utilizado hasta ahora.
Lo del formulario modal no te entendía bien la intención, vale, ahora lo entiendo,
Dos:
- Que cada usuario trabaje directamente con tablas locales donde pueda leer y editar sin problemas y luego hacer una carga a las tablas en red.
Esto no lo entiendo muy bien. Supongo que se refiere a que el usuario cuando quiera leer o editar algún registro, copie el registro de la tabla de red a una tabla local y desde allí trabajar. ¿Pero esto sería un poco como la primera alternativa no, en cuanto a que el acceso a los datos sería los que hay en red y sería en modo lectura, con la diferencia que si va a hacer alguna modificación, copiar los datos a la tabla local y después ésta a la de red. Entiendo que todo esto con la finalidad de aprovechar el formulario enlazado. ¿es correcto o me he liado?
Decir que solo serían 2 usuarios y que además cada uno trabajará con su propio grupo de registros y el resto solo de consulta. Tampoco necesito que los datos en red estén actualizados al instante.
La primera alternativa la entiendo mejor y no me da miedo, que aunque seguro tendré que preguntar, tengo algo de conocimiento de sql y los recordset. ¿Le he entendido bien, qué alternativa cree que es la mejor y también la más sencilla?
Saludos,
Siento la demora, el foro no envía mensajes ni actualiza cálculos de actividad por lo que los seguimientos son complicados,
Sobre la duda de lo que ocurre cuando un usuario abre un formulario de solo lectura:
Lo mismo que cuando alguien se detiene ante un escaparate y divaga que prenda o articulo le conviene mas... NADA.
Eso si, en cuanto cambie el modo de trabajo (lo abra en modo lectura escritura, esto es: entre en la tienda para comprar) las prendas o artículos que seleccione para ir al probador no estarán disponibles para cualquier otro cliente.
Cuando finalice su compra (cuando finalice los cambios y guarde el registro) lo que quede en la tienda estará nuevamente a disposición del resto de clientes. ¿Soluciona la duda?.
Sobre la copia ...
También se puede intentar asociar a la respuesta anterior, pongamos que la compra o venta se hace a distancia, para lo cual se genera una lista de favoritos (prendas o artículos de nuestro interés) y con esa lista (los datos en una copia local de la tabla) se toman decisiones (colores, tallas ...), una vez que se alcanza la decisión definitiva (incluida la de borrar el catalogo, es virtual esto es: 'una copia sin valor')
Tras la decisión se elige la talla (incluso retoques para que se adapte al fin destinado) y se actualiza el pedido.
Este es el único momento en que se bloquean los orígenes de datos, algo que no suele ser traumático, ya que se encolan las peticiones (y Access espera en estos casos).
Del buen funcionamiento del almacén y de la calidad de los pedidos (que no falten datos etc.) dependerán las demoras y eso es algo contra lo no pueden hacer nada las bases de datos, si solo hay una ventana para recoger los encargos, que exista cola o no dependerá normalmente de la calidad del servicio.
En este punto, creo que con dos usuarios y conjuntos de datos independientes (aunque comparten otros que mas bien serán estáticos, esto es, de solo lectura) la opción de vincular parece mas interesante, pues las actualizaciones o creaciones pueden hacerse con SQL (consultas de anexado o de actualización).
Conviene que al finalizar se haga una actualización (Requery) para mostrar el resultado.