ms access - una - Configuración de un MS-Access DB para acceso multiusuario

no es una ruta de acceso valida access (7)

Access es una gran base de datos multiusuario. Tiene muchas características integradas para manejar la situación de multiusuario. De hecho, es muy popular porque es una gran base de datos multiusuario. Existe un límite superior para la cantidad de usuarios que pueden usar la base de datos al mismo tiempo y realizar actualizaciones y ediciones, dependiendo de qué tan bien informado esté el desarrollador sobre el acceso y cómo se ha diseñado la base de datos, desde 20 usuarios hasta aproximadamente 50 usuarios. Algunas bases de datos de acceso se pueden construir para manejar hasta 50 usuarios concurrentes, mientras que muchas otras pueden manejar 20 o 25 usuarios simultáneos actualizando la base de datos. Estas cifras se han observado para bases de datos que han estado en uso durante varios años o más y se han discutido muchas veces en los grupos de noticias de acceso.

Estamos pensando en "hacer crecer" un poco de MS-Access DB con algunas tablas, formularios y consultas para múltiples usuarios. (El uso de un back-end diferente es otro, pero es una opción más a largo plazo que desafortunadamente no es aceptable en la actualidad).
La mayoría de los usuarios serán de solo lectura, pero habrá unos pocos (actualmente uno o dos) usuarios que deben poder hacer cambios (mientras que los usuarios de solo lectura también usan la base de datos). No nos preocupan tanto los aspectos de seguridad, sino más sobre algunos de los siguientes problemas:

¿Cómo podemos asegurarnos de que el usuario de escritura pueda realizar cambios en los datos de la tabla mientras otros usuarios usan los datos? ¿Los usuarios leídos ponen bloqueos en las tablas? ¿El usuario de escritura tiene que poner bloqueos en la mesa? ¿Access hace esto por nosotros o tenemos que codificarlo explícitamente?
¿Hay algún problema común con las "transacciones de acceso a MS" que debemos tener en cuenta?
¿Podemos trabajar en formularios, consultas, etc. mientras se utilizan? ¿Cómo podemos "programar" sin estar en el camino de los usuarios?
¿Qué configuración en MS Access tiene una influencia sobre cómo se manejan las cosas?
Nuestra experiencia se basa principalmente en Oracle, ¿dónde es diferente el acceso para el manejo de múltiples usuarios? ¿Hay algo así como "niveles de aislamiento" en Access?

Cualquier consejo o sugerencia para artículos útiles sería muy apreciado.

El bloqueo de tabla o registro está disponible en Access durante las escrituras de datos. Puede controlar el bloqueo de registro predeterminado a través de Herramientas | Opciones | Lengüeta avanzada:

Sin cerraduras
Todos los registros
Registro editado

Puede configurar esto en los bloqueos de grabación de un formulario o en su código DAO / ADO para necesidades específicas.

Las transacciones no deberían ser un problema si las usa correctamente.

Práctica recomendada: separa tus tablas de Todos tus otros códigos. Dé a cada usuario su propia copia del archivo de código y luego comparta el archivo de datos en un servidor de red. Trabaje en una copia de ''prueba'' del código (y un enlace a un archivo de datos de prueba) y luego actualice los archivos de códigos individuales del usuario por separado. Si necesita realizar cambios en el archivo de datos (agregar tablas, columnas, etc.), deberá hacer que todos los usuarios salgan de la aplicación para realizar los cambios.

Ver otras respuestas para la comparación de Oracle.

Encuentro que las respuestas a esta pregunta son problemáticas, confusas e incompletas, así que me esforzaré por hacerlo mejor.

P1: ¿Cómo podemos asegurarnos de que el usuario de escritura pueda realizar cambios en los datos de la tabla mientras otros usuarios usan los datos? ¿Los usuarios leídos ponen bloqueos en las tablas? ¿El usuario de escritura tiene que poner bloqueos en la mesa? ¿Access hace esto por nosotros o tenemos que codificarlo explícitamente?

Nadie realmente ha respondido esto de manera completa. La información sobre el establecimiento de bloqueos en las opciones de acceso no tiene nada que ver con el bloqueo de lectura contra escritura. Sin bloqueos frente a todos los registros frente a registro editado es cómo establece el bloqueo de registro predeterminado para ESCRITOS.

Sin bloqueos significa que está utilizando el bloqueo OPTIMISTIC, lo que significa que permite que varios usuarios editen el registro y luego les informa si el registro ha cambiado desde que lanzaron sus propias ediciones. El bloqueo optimista es lo que debe comenzar, ya que no requiere codificación para implementarlo, y para poblaciones de usuarios pequeños casi nunca causa un problema.
Todos los registros significa que toda la tabla está bloqueada cada vez que se inicia una edición.
Registro editado significa que hay menos registros bloqueados, pero si es un registro único o más de un registro depende de si su base de datos está configurada para usar el bloqueo de nivel de registro (primero agregado en Jet 4) o el bloqueo de nivel de página. Francamente, nunca pensé que valga la pena instalar un bloqueo de nivel récord, ya que el bloqueo optimista soluciona la mayoría de los problemas.

Uno podría pensar que quiere usar el bloqueo pesimista de nivel de registro, pero el hecho es que en la gran mayoría de las aplicaciones, dos usuarios casi nunca editan el mismo registro. Ahora, obviamente, ciertos tipos de aplicaciones podrían ser excepciones a eso, pero si me topaba con una aplicación así, probablemente trataría de ingeniarla rediseñando el esquema para que sea muy raro que dos usuarios editen el mismo grabar (generalmente yendo a alguna forma de edición transaccional, donde los cambios se realizan agregando registros, en lugar de editar los datos existentes).

Ahora, para su pregunta real, hay varias formas de limitar a algunos usuarios a solo lectura y otorgar privilegios de escritura a otros. La seguridad a nivel de usuario de Jet fue pensada para este fin y funciona bien en la medida en que es una "seguridad" para cualquier definición significativa del término. En general, siempre que use un almacén de datos Jet / ACE, la mejor seguridad que obtendrá es la proporcionada por Jet ULS. Es crackable, sí, pero tus usuarios estarían cometiendo una ofensa al romperla, por lo que podría ser suficiente.

Tiendo a no implementar Jet ULS en absoluto y en lugar de eso, simplemente diseñé los formularios de edición de datos de modo que revisaran el inicio de sesión de Windows del usuario e hicieran los formularios de solo lectura o escritura dependiendo de qué usuarios debían obtener el acceso. Queda o no depende de usted registrar la pertenencia a un grupo en una tabla de datos o mantener los grupos de seguridad de Windows para este fin. También puede usar un archivo de grupo de trabajo Jet para manejarlo y proporcionar un archivo system.mdw diferente para los usuarios de escritura. Los usuarios de solo lectura iniciarían sesión de forma transparente como administrador, y aquellos que iniciaron sesión como administrador recibirían solo acceso de solo lectura. Los usuarios de escritura iniciarían sesión como algún otro nombre de usuario (de forma transparente, en el acceso directo que les proporcionó para iniciar la aplicación, sin proporcionar contraseña), y que se usaría para configurar los formularios como de lectura o escritura.

Si usas Jet ULS, puede ser realmente peludo hacerlo bien. Implica bloquear todas las tablas como de solo lectura (o tal vez ni siquiera eso) y luego usar consultas RWOP para proporcionar acceso a los datos. No he hecho más que una de esas aplicaciones en mis 14 años de desarrollo profesional de Access.

Para resumir mis respuestas a las partes de su pregunta:

¿Cómo podemos asegurarnos de que el usuario de escritura pueda realizar cambios en los datos de la tabla mientras otros usuarios usan los datos?

Yo recomendaría hacer esto en la aplicación, configurando formularios para leer / solo o editable en tiempo de ejecución dependiendo del inicio de sesión del usuario. El enfoque más fácil es configurar los formularios para que sean de solo lectura y cambien a editables para los usuarios de escritura cuando abren el formulario.

¿Los usuarios leídos ponen bloqueos en las tablas?

No en ningún sentido significativo. Jet / ACE tiene bloqueos de lectura, pero solo están allí para mantener el estado de las vistas individuales y para actualizar los datos para el usuario. No bloquean las operaciones de escritura de ningún tipo, aunque la sobrecarga de su seguimiento en teoría ralentiza las cosas. No es suficiente de lo que preocuparse.

¿El usuario de escritura tiene que poner bloqueos en la mesa?

El acceso en combinación con Jet / ACE hace esto por usted automáticamente, especialmente si elige el bloqueo optimista como su predeterminado. El punto clave aquí es que las aplicaciones de acceso están enlazadas por datos, por lo que tan pronto como se carga un formulario, el registro tiene un bloqueo de lectura, y tan pronto como se edite el registro, si está o no bloqueado para otros usuarios está determinado por si está utilizando un bloqueo optimista o pesimista. De nuevo, este es el tipo de cosas que Access cuida para usted con sus comportamientos predeterminados en formularios enlazados. No te preocupes por nada de eso hasta el momento en que encuentres problemas.

¿Access hace esto por nosotros o tenemos que codificarlo explícitamente?

Básicamente, aparte de establecer la capacidad de edición en el tiempo de ejecución (de acuerdo con quién tiene acceso de escritura), no se necesita codificación si está utilizando el bloqueo optimista. Con el bloqueo pesimista, no tiene que codificar, pero casi siempre tendrá que hacerlo, ya que no puede simplemente dejar al usuario atrapado con los comportamientos predeterminados y los mensajes de error.

P2: ¿Hay algún problema común con las "transacciones de acceso a MS" que debamos tener en cuenta?

Jet / ACE tiene soporte para transacciones de compromiso / retrotracción, pero no me queda claro si eso es lo que quiere decir en esta pregunta. En general, no utilizo transacciones excepto para mantener la atomicidad, por ejemplo, al crear una factura o al hacer cualquier actualización que involucre varias tablas. Funciona de la forma en que lo esperaría, pero no es realmente necesario para la gran mayoría de las operaciones en una aplicación de Access.

Quizás uno de los problemas aquí (especialmente a la luz de la primera pregunta) es que quizás no comprenda que Access está diseñado para crear aplicaciones con datos vinculados a los formularios. "Transacciones" es un tema de gran importancia para aplicaciones independientes y sin estado (por ejemplo, basadas en navegador), pero para aplicaciones encuadernadas en datos, la edición y el guardado todo sucede de forma transparente.

Para ciertos tipos de operaciones, esto puede ser problemático, y ocasionalmente es apropiado editar datos en Access con formularios independientes. Pero eso es muy raro, en mi experiencia. No es que no use formularios independientes, los utilizo para diálogos y cosas por el estilo, sino que mis aplicaciones no editan tablas de datos con formularios independientes. Con casi ninguna excepción, todas mis aplicaciones editan datos con formularios enlazados.

Ahora, los formularios no vinculados son bastante fáciles de implementar en Access (especialmente si nombra los controles de edición de la misma manera que los campos subyacentes), pero ir con los formularios de edición de datos sin vincular es realmente perder el punto de acceso, que es que el enlace es todo hecho para ti. Y el principal inconveniente de ir desatado es que pierdes todos los eventos de formulario de nivel de registro, como OnInsert, BeforeUpdate y así sucesivamente.

Q3. ¿Podemos trabajar en formularios, consultas, etc. mientras se utilizan? ¿Cómo podemos "programar" sin estar en el camino de los usuarios?

Esta es una de las preguntas que ha sido bien abordada. Todas las aplicaciones de acceso multiusuario o replicado se deben dividir, y la mayoría de las aplicaciones de usuario único también deben estarlo. Es un buen diseño y también hace que las aplicaciones sean más estables, ya que solo las tablas de datos terminan siendo abiertas por más de un usuario a la vez.

Q4. ¿Qué configuración en MS Access tiene una influencia sobre cómo se manejan las cosas?

"¿Cosas?" ¿Qué cosas?

Q5. Nuestra experiencia se basa principalmente en Oracle, ¿dónde es diferente el acceso para el manejo de múltiples usuarios? ¿Hay algo así como "niveles de aislamiento" en Access?

No sé nada específicamente sobre Oracle (ninguno de mis clientes podría permitírselo aunque lo quisieran), pero pedir una comparación de Access y Oracle revela un malentendido fundamental en algún momento.

Access es una herramienta de desarrollo de aplicaciones.

Oracle es un servidor de base de datos de fortaleza industrial.

Manzanas y naranjas.

Ahora, por supuesto, Access se envía con un motor de base de datos predeterminado, originalmente llamado Jet y ahora revisado y renombrado como ACE, pero hay muchos niveles en los que Access desaparece completamente de Jet / ACE, el motor de base de datos predeterminado.

En este caso, ha elegido usar un back end Jet / ACE, que probablemente sea adecuado para pequeñas poblaciones de usuarios, es decir, menores de 25. Jet / ACE también puede estar bien hasta 50 o 100, particularmente cuando solo un algunos de los usuarios simultáneos tienen permiso de escritura. Mientras que el límite de 255 usuarios en Jet / ACE incluye tanto usuarios de solo lectura como de escritura, es el número de usuarios de escritura el que realmente controla cuántos usuarios simultáneos puedes admitir, y en tu caso, tienes una aplicación con mayor cantidad de lecturas -Sólo usuarios, por lo que no debería ser terriblemente difícil diseñar una buena aplicación que no tenga problemas con el back-end.

Básicamente, creo que su experiencia en Oracle probablemente lo lleve a malinterpretar cómo desarrollarse en Access, donde el enfoque esperado es vincular sus formularios a fuentes de registros que se actualizan sin necesidad de escribir código. Ahora, por razones de eficiencia, es una buena idea vincular sus formularios a subconjuntos de registros, en lugar de a tablas completas, pero incluso con una tabla completa en la fuente de registros detrás de un formulario de edición de datos, Access será bastante eficiente en la edición de Jet / Tablas de ACE (el viejo mito sobre tirar toda la mesa a través del cable todavía está ahí) siempre que sus tablas de datos estén indexadas de manera eficiente.

El bloqueo de registros es algo sobre lo que en su mayoría no debería preocuparse, y una de las razones es la edición encuadernada, donde el formulario sabe lo que está sucediendo en el back-end en todo momento (bueno, a intervalos de alrededor de un segundo aparte, el intervalo de actualización predeterminado). Es decir, no es como una página web donde recuperas una copia de los datos y luego publicas tus ediciones en el servidor en una transacción completamente desconectada de la operación de recuperación de datos original. En un entorno enlazado como Access, el archivo de bloqueo en el archivo de datos de fondo siempre va a hacer un seguimiento del hecho de que alguien tiene el registro abierto para editar. Esto evita que las ediciones de un usuario pisen las ediciones de otra persona, porque Access conoce el estado e informa al usuario. Todo esto ocurre sin ninguna codificación por parte del desarrollador y es una de las grandes ventajas del modelo de edición encuadernado (además de no tener que escribir código para publicar las ediciones).

Para todos aquellos que son experimentados programadores de bases de datos familiarizados con otras plataformas que vienen a Access por primera vez, les recomiendo usar Access como un usuario final. Pruebe todas las funciones de apuntar y hacer clic. Ejecute el formulario e informes de asistentes y revise los resultados que producen. No puedo garantizar que todos ellos demuestren buenas prácticas, pero definitivamente demuestran las suposiciones predeterminadas detrás de la forma en que se pretende utilizar Access.

Si te encuentras escribiendo mucho código, es probable que te falte el punto de acceso.

He encontrado el protocolo SMB2 introducido en Vista para bloquear las bases de datos de acceso. Puede ser deshabilitado por el siguiente regedit:

Editor de registro de Windows versión 5.00

[HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / services / LanmanServer / Parameters] "Smb2" = dword: 00000000

La forma correcta de crear aplicaciones cliente / servidor de Microsoft Access donde se almacenan los datos en un RDBMS es utilizar el método de tabla vinculada. Esto garantiza que el aislamiento de datos y la simultaneidad se mantengan entre la aplicación de cliente de Microsoft Access y los datos RDBMS sin una lógica de programación adicional y un código innecesario que dificulta el mantenimiento y aumenta el tiempo de desarrollo.

ver: http://claysql.blogspot.com/2014/08/normal-0-false-false-false-en-us-x-none.html

Lo primero que debe hacer (si no lo hizo) es dividir su base de datos en una interfaz (con todos los formularios / informes, etc.) y un back-end (con todos los datos). Lo segundo es configurar el control de versiones en la interfaz.

La forma en que lo he hecho en muchas de mis bases de datos es hacer que los usuarios ejecuten una pequeña base de datos "jumper" para abrir la base de datos principal. Este saltador hace las siguientes cosas

• Verifica si el usuario tiene la base de datos en su disco C

• Si no lo hacen, entonces instala y ejecuta

• Si lo hacen, comprueba qué versión tienen

• Si los números de versión no coinciden, copie la última versión

• Abra la base de datos

Todo este proceso de verificación normalmente toma menos de medio segundo. Usando este modelo puede hacer todo su desarrollo en una base de datos separada y luego, cuando esté listo para "liberar", simplemente coloque el nuevo dispositivo en el recurso compartido de red y la próxima vez que el usuario abra el puente, se copie la última versión.

También hay otras cosas en las que pensar en una base de datos multiusuario y podría valer la pena verificar los errores comunes, como vincular un formulario a una tabla completa, etc.

creo que Access es la mejor opción para tu caso. Pero debe dividir la base de datos, consulte: http://accessblog.net/2005/07/how-to-split-database-into-be-and-fe.html

• ¿Cómo podemos asegurarnos de que el usuario de escritura pueda realizar cambios en los datos de la tabla mientras otros usuarios usan los datos? ¿Los usuarios leídos ponen bloqueos en las tablas? ¿El usuario de escritura tiene que poner bloqueos en la mesa? ¿Access hace esto por nosotros o tenemos que codificarlo explícitamente?

no hay bloqueos de lectura a menos que los pones explícitamente. Solo usa "No Locks"

• ¿Hay algún problema común con las "transacciones de acceso a MS" que debemos tener en cuenta?

no debería haber problemas con 1-2 usuarios de escritura

• ¿Podemos trabajar en formularios, consultas, etc. mientras se utilizan? ¿Cómo podemos "programar" sin estar en el camino de los usuarios?

si divide la base de datos, entonces no hay problema para trabajar en el diseño de FE.

• ¿Qué configuración en MS Access tiene una influencia sobre cómo se manejan las cosas?

¿Qué quieres decir?

• Nuestra experiencia se basa principalmente en Oracle, ¿dónde es diferente el acceso para el manejo de múltiples usuarios? ¿Hay algo así como "niveles de aislamiento" en Access?

sin niveles de aislamiento en el acceso. Por cierto, luego puede mover los datos a Oracle y mantener la interfaz de acceso, si tiene muchos usuarios y una gran base de datos.