.net - Concurrencia de MS Access(MDB)

database ms-access (11)

Para un proyecto pequeño, necesito utilizar una base de datos simple con requisitos muy ligeros: pocas tablas, no más de unos pocos miles de registros en total, 2 o 3 usuarios. Estoy trabajando en el entorno .NET.

Como servidor de base de datos (incluso esas ediciones Express) parece una gran exageración en este caso, una base de datos MDB muy simple podría hacer para la mayoría de los requisitos. Sin embargo, estoy preocupado por la concurrencia. Mi idea es colocar el archivo .mdb en un recurso compartido de red y permitir que los usuarios accedan a este archivo desde sus clientes basados en .NET. El db está principalmente dirigido a operaciones de solo lectura, pero los usuarios ocasionalmente necesitarán actualizar / eliminar registros también. Si esto no será posible en ese momento (debido a que el archivo db está bloqueado o lo que sea), puedo mantener las actualizaciones en el cliente y procesarlas en otro momento.

La pregunta en sí misma va sobre estos puntos:

¿Cómo se manejan las lecturas simultáneas en MDB?
¿Cómo se manejan las actualizaciones / eliminaciones simultáneas en MDB?
¿Existe un concepto de bloqueos y cómo puedo aprovecharlo en una aplicación .NET?
¿Es bueno o horrible que se coloque el archivo MDB en una red?

Como estoy trabajando en .NET, también me gustaría saber cómo puedo detectar cualquier problema de simultaneidad y tomar las medidas adecuadas. Es decir, ¿qué excepción debería detectar y qué medida recomendaría tomar?

EDITAR : Puede ser mi mala descripción del problema, pero la mayoría de las respuestas parecen aconsejar un servidor de bases de datos completo. Entiendo las diferencias y los beneficios de tener una instalación de servidor y, de hecho, he implementado una cantidad considerable de proyectos en MSSQL y Oracle. En esta pregunta, sin embargo, solo me preocupan los problemas de acceso y concurrencia, por lo que no sugiera un servidor db.

Gracias por tu ayuda.

Creé una docena de aplicaciones para pequeñas empresas en Access a lo largo de los años. La mayoría tiene un máximo de 10 a 20 usuarios a la vez. Las bases de datos se dividen entre una "aplicación" y una base de datos "de datos". El rendimiento es decente y no hay problemas con la concurrencia. También la corrupción ha sido básicamente inexistente desde Access 2000 SP2.

Hay mucha gente que dice "nunca utilices Access", bueno, si se hace bien (es decir, por un desarrollador profesional) Access es un paquete de desarrollo bastante bueno y me he ganado la vida. Mis clientes están muy contentos con lo que construí.

Creo que puedes definirlo en tu cadena de conexión a la aplicación .net. Busqué en Google para JET, acceso y registro de bloqueo

aquí hay un link que podría ayudar.

Consulte la respuesta aceptada para obtener detalles reales sobre cómo Access y JET obtienen datos.

Cuando vaya con un recurso compartido de red, iría con una base de datos habilitada para la red (mysql / firebird / mssql) en lugar de acceso.

Para la situación, su descripción usando Access no sería un problema.

Utilicé Access en situaciones más desafiantes, sobre todo cuando trabajo con sitios web cuando Access no se usa indebidamente más allá de lo que realmente no es tan malo como un motor de base de datos. (sin hablar de formularios y cosas así, solo tablas y registros)

Cuando haces inserciones / actualizaciones / elimina de varios usuarios a la vez, se pone un poco complicado. Este es el punto donde comienzas a pensar en motores de bases de datos reales.

Además, cuando desee una base de datos de bajo costo que sea segura para hilos, puede echar un vistazo a vistadb (más lento que el acceso, no siempre libre, 100% .NET)

Creo que el acceso usa bloqueos a nivel de tabla con algún tipo de mecanismo de sincronización. Las cosas deberían funcionar bien. Si le preocupa, siempre puede realizar una prueba de esfuerzo simulada.

El acceso es realmente una solución de escritorio, de usuario único. En la práctica, tiene un límite de usuario superior de "uno".

También es un motor local. Es decir, cuando ejecuta una consulta, los datos se transfieren a través de la red al motor JET local para su procesamiento. Se coloca un archivo .ldb en el recurso compartido de red para controlar bloqueos.

Si utiliza un motor del lado del servidor (MSSQL, MySQL, Sybase, ''Orable, etc.), entonces envía una consulta a un motor que lo procesa y le devuelve los resultados. Las cerraduras se llevan a cabo internamente.

Esto tiene enormes implicaciones para el rendimiento, la estabilidad y la integridad de los datos.

Si su usuario decide presionar el botón de reinicio, la base de datos de Access tiene una buena probabilidad de corromperse y deberá eliminar el archivo .ldb.

Con un motor de base de datos adecuado (MSSQL, Sybase, ''Orable: no me gustan las copias de seguridad de MySQL), entonces también tiene una capacidad de respaldo adecuada. A menos que tenga un software inteligente para respaldar archivos inutilizados, es posible que no tenga copias de seguridad de sus datos en Access DB.

Mencioné bloqueos específicamente porque un motor db puede manejar la concurrencia y la transacción de manera mucho más eficiente y elegante que cualquier sistema basado en archivos.

Puedo ver el uso de un proyecto de Access como una interfaz para un motor de base de datos, pero no para invertir en una aplicación cliente completa con un back-end de Access.

Esta es una vieja pregunta, pero nadie en realidad la ha respondido. Aquí están las preguntas:

¿Cómo se manejan las lecturas simultáneas en MDB?
¿Cómo se manejan las actualizaciones / eliminaciones simultáneas en MDB?
¿Existe un concepto de bloqueos y cómo puedo aprovecharlo en una aplicación .NET?
¿Es bueno o horrible que se coloque el archivo MDB en una red?

Las dos primeras preguntas básicamente se pueden responder con una explicación. Una advertencia clave aquí: las respuestas que ofrezco aquí son específicas de los MDB de Jet (y sus variantes) y no se aplican por completo al nuevo formato de archivo introducido comenzando con A2007, es decir, formato ACCDB. No he explorado completamente las implicaciones de la eliminación de Jet ULS del ACE y algunos de los comentarios a continuación pueden suponer que Jet ULS está debajo del capó. Sin embargo, para muchas cosas, puede sustituir "archivo LACCDB" por "archivo LDB" y los resultados serán los mismos.

1-2) Lecturas / actualizaciones / eliminaciones concurrentes

El motor de la base de datos Jet a menudo se denomina base de datos "servidor de archivos" en el sentido de que no hay demonios que administren E / S del lado del servidor con los archivos de datos en el servidor. Lo que esto significa es que todos los clientes que usan un Jet MDB están leyendo el archivo directamente.

Eso es, por supuesto, una receta para el desastre si no hay un mecanismo incorporado para manejar el acceso concurrente al archivo.

Jet usa un archivo de bloqueo de registros, donde si su MDB es "MyFile.MDB", el archivo de bloqueo de registros estará en la misma carpeta y se llamará "MyFile.LDB". El archivo LDB registra qué usuarios de Jet ULS tienen abierto el archivo MDB, de qué estación de trabajo está conectado ese usuario y toda la información necesaria para negociar problemas de concurrencia.

Ahora, para aquellos que cortan los dientes en motores de bases de datos cliente / servidor, esto puede parecer primitivo y peligroso, pero en el momento en que se desarrolló el motor de base de datos Jet, su propósito era ser utilizado como motor de base de datos de escritorio para pequeños grupos de trabajo, y estaba compitiendo con otros motores db de escritorio como xBase y Paradox, los cuales usaban archivos de bloqueo análogos para administrar el uso concurrente de archivos de datos de múltiples clientes.

Dentro de un archivo de base de datos Jet, los bloqueos se aplican en las páginas de datos (que en Jet 4 se incrementaron a 4K, mientras que en Jet 3.x y antes, fueron 2K), o en el nivel de registro si la tabla de datos se creó originalmente para usa el bloqueo de nivel de registro. En los primeros días de Jet 4, muchos encontraron que el bloqueo de nivel de registro era bastante lento, particularmente cuando se usaba bloqueo pesimista, por lo que muchos desarrolladores de Access nunca usaron nada más que el bloqueo de nivel de página (¡@David Fenton levanta la mano!).

De hecho, cuando usa el bloqueo optimista, evita la mayoría de los problemas de concurrencia que vendrían con el bloqueo pesimista.

Algunas advertencias:

desde DAO, el bloqueo de nivel de registro no está disponible, y solo obtiene el bloqueo de nivel de página.
desde DAO, hay varias opciones para controlar el bloqueo optimista / pesimista, en particular el argumento LockEdits del método OpenRecordset, pero que también interactúa con cierta configuración especificada en el argumento Opciones de OpenRecordset (por ejemplo, la opción dbReadOnly no se puede usar con LockEdits). Además del bloqueo, también hay opciones para actualizaciones consistentes / inconsistentes, y todo esto puede interactuar con las transacciones (por ejemplo, los cambios dentro de una transacción sin procesar no serán visibles para otros usuarios y por lo tanto no entrarán en conflicto con ellos, pero puede poner bloqueos de solo lectura en las tablas involucradas).

Desde ADO / OLEDB, estas estructuras de control de concurrencia de Jet se correlacionarán con las funciones y argumentos relevantes que se encuentran en ADO / OLEDB. Como utilizo Jet solo desde Access, solo interactúo con DAO, por lo que no puedo aconsejar sobre cómo controlarlos con ADO / OLEDB, pero el hecho es que el motor de la base de datos Jet ofrece control de su bloqueo de registros al acceder a él. programáticamente (a diferencia de a través de la IU de acceso): es simplemente más complicado.

3) Cerraduras y .NET

No puedo ofrecer ningún consejo aquí, aparte de que probablemente usaría OLEDB como su interfaz de datos, pero el punto es que la función / control de bloqueo está ahí en el motor de db, así que es probable que haya una manera de controlarlo a través de OLEDB. Sin embargo, puede no ser bonito, ya que me parece que OLEDB está diseñado en torno a arquitecturas de cliente / servidor, y el bloqueo basado en archivos de Jet puede no corresponderse con eso de una manera elegante.

4) MDB en una red compartida

Jet es muy sensible al más mínimo inconveniente en cualquier conexión de red. Debido a eso, las redes de bajo ancho de banda pueden aumentar la vulnerabilidad de las bases de datos de Jet abiertas a través de una conexión lenta.

Esto se debe a que los principales fragmentos del archivo de la base de datos deben pasar por el cable hasta la RAM de la computadora local para su procesamiento. Ahora, muchas personas afirman erróneamente que todo el archivo MDB se ha transferido a través del cable, o que las tablas completas se han transferido a través del cable. Esto no es verdad. En cambio, Jet primero solicita los índices (y las solicitudes no son más que necesarias para cumplir con la consulta) y luego, a partir de ese resultado, determina exactamente qué páginas de datos se necesitan y luego solo extrae esas páginas. Esto es sorprendentemente eficiente y rápido.

Además, Jet hace un almacenamiento en caché muy inteligente que puede significar que una primera solicitud de datos puede tardar un tiempo, pero las solicitudes posteriores de los mismos datos ocurren casi instantáneamente debido al almacenamiento en caché.

Ahora bien, si no ha indexado bien sus tablas, puede terminar tirando de la tabla completa y haciendo un escaneo completo de la tabla. Del mismo modo, si basa los criterios en las funciones del lado del cliente que no forman parte del dialecto SQL de Jet, podría terminar tirando de una tabla completa (es posible que la clasificación, por ejemplo, Reemplazar (MyField, "A", "Z") una exploración de tabla completa). Pero ese tipo de cosas también serán ineficientes con una arquitectura de cliente / servidor, por lo que es solo un diseño de esquema de sentido común para indexar cosas correctamente y tener cuidado con el uso de UDF o funciones no compatibles con Jet. En general, las mismas cosas que son eficientes con el cliente / servidor van a ser eficientes con Jet (la principal diferencia es que con Jet está mejor con una conexión persistente para evitar la sobrecarga de recreación del archivo LDB, que es significante).

Otra cosa que debes evitar es tratar de usar los datos de Jet a través de una conexión WiFi. Todos sabemos cuán poco confiable es el WiFi, y es solo pedir problemas para tratar de trabajar con datos de Jet a través de una conexión WiFi.

La línea de fondo:

Si está utilizando un MDB como almacén de datos para servir datos de un servidor web, debe colocar los datos lo más cerca posible de la RAM del servidor web. Eso significa que, cuando sea posible, en un volumen de disco que esté conectado al servidor web físico. Donde eso no es posible, quiere una conexión LAN rápida y confiable. Las LAN de GB en los centros de datos son bastante comunes en estos días y me sentiría muy cómodo trabajando con los datos de Jet en ese tipo de conexión.

Para uso compartido, por ejemplo, varias estaciones de trabajo cliente que ejecutan una aplicación de escritorio VB.NET que comparte un solo Jet MDB como almacén de datos, es bastante seguro tener el archivo de datos en un servidor de archivos confiable. Siempre que sea posible, es una buena idea colocar sus archivos Jet MDB en máquinas que no sirven para varios propósitos (por ejemplo, su controlador de dominio que ejecuta Exchange, SQL Server y que actúa como servidor de archivos y el servidor de impresión puede no ser la mejor ubicación) . Las aplicaciones como Exchange pueden interferir gravemente con la funcionalidad del servidor de archivos, y generalmente recomiendo no colocar los archivos MDB en un servidor multitarea como servidor Exchange a menos que el volumen sea extremadamente bajo.

Otras Consideraciones:

nunca intente distribuir un MDB en un sistema de archivos replicado, a menos que todos los usuarios estén usando la misma réplica. Es decir, si tiene dos servidores que replican archivos entre ellos, ni siquiera piense en editar el archivo MDB de ambos servidores. Esto dañará el archivo casi de inmediato.
Recomendaría no almacenar ningún MDB en ningún otro que no sea un sistema de archivos nativo de Windows servido a través de una red nativa de Microsoft SMB. Esto significa que no hay Novell, ni Linux, ni SAMBA. La razón principal de esto es que aparentemente hay ganchos de bajo nivel de Jet en algunas funcionalidades de bloqueo de bajo nivel en el sistema de archivos de Windows que no están 100% replicadas en otros systs de archivos. Ahora, soy muy conservador en esto, y muchos desarrolladores competentes de Access han reportado excelentes resultados con servidores de archivos de Novell configurados correctamente (a menudo es necesario que haya algunos ajustes de bloqueo de registros, aunque eso puede ser menos relevante en estos días). ni siquiera sé si Novell existe más), y un rendimiento increíble con servidores de archivos basados en Linux que ejecutan SAMBA. Soy cauteloso en esto y recomendaría cualquier cliente en contra de esto (esto incluye varios dispositivos SAN, también, ya que no muchos de ellos están basados en Windows).
Nunca los ejecutaría en ningún sistema de archivos virtualizado por las mismas razones. Sin embargo, tengo un cliente que ha estado ejecutando su aplicación de acceso de usuario único bajo Parallels en Mac Air durante varios años sin ningún problema. Pero es un usuario único, por lo que los problemas de bloqueo serán relativamente menores.

No sé si eso responde tus preguntas o no. Todo se basa en mis 13 años de uso habitual de Jet como desarrollador de Access y en el estudio del único libro publicado sobre Jet, la Guía de programadores de motores de base de datos de Jet (solo para Jet 3.5). No he proporcionado ninguna cita real, pero si alguien necesita algunos detalles sobre cualquier cosa que he dicho, haré la investigación si puedo.

He escrito dos productos comerciales que usan una base de datos de Access, que se ejecuta desde un recurso compartido de red, para un máximo de 10 usuarios. Si no lo abusas, realmente no hay problema; pero como puede ver, muchos desarrolladores nunca llegan allí, y debido a su naturaleza baja, hay una gran cantidad de piratas informáticos creados en él. En el caso de un producto, tuve que rediseñar la aplicación debido a todos los problemas descritos en detalle por otros; pero después de limpiarlo, nunca tuve un problema de integridad de la base de datos en cientos de instalaciones.

Su gran ventaja es la base de datos de un solo archivo, que es fácil de realizar una copia de seguridad, restaurar y copiar a su computadora portátil para diseccionar. Prácticamente todas las alternativas, incluida sqlite (aunque algunos no lo admiten), requieren alguna forma de atención de DBA de vez en cuando.

En la mayoría de los casos, Access proporciona bloqueos de registros y bloqueos de archivos para algunos DDL (por ejemplo, cambios de esquema) de forma predeterminada.

Pero Microsoft básicamente lo está obsoletando, y algunos de sus colegas se burlarán de usted por usarlo.

(En este punto, normalmente me escondo y digo "INCOMING !!!")

He estado usando Access, o más correctamente, Jet como back-end en un sitio privado muy pequeño que nunca puede crecer ya que está limitado por el tamaño de una profesión en este pequeño país. En tres años no he tenido ningún problema. Hay menos de 100 usuarios, con alrededor de treinta a cuarenta que lo usan todos los días. Las tablas tienen algunos miles de registros.

No tengo mucha experiencia con Access, pero este enlace puede serle útil:

http://office.microsoft.com/en-us/access/HP052408601033.aspx

"Puede poner toda la base de datos de Access en un servidor de red o en una carpeta compartida. Este es el método más fácil de implementar. Todos comparten los datos y usan los mismos formularios, informes, consultas, macros y módulos. Use esta estrategia si quiere que todos utilicen la base de datos de Access de la misma manera o si no puede ayudar a los usuarios a crear sus propios objetos ".

"Cuando abre un archivo de base de datos de Access (.mdb) en modo compartido, Microsoft Access también crea un archivo de información de bloqueo (.ldb) con el mismo nombre de archivo (por ejemplo, Northwind.ldb) y en la misma carpeta que el archivo de base de datos Este archivo de información de bloqueo almacena el nombre de la computadora (como mypc) y el nombre de seguridad (como Admin) de cada usuario compartido de la base de datos. Microsoft Access usa esta información para controlar la concurrencia. En la mayoría de los casos, Microsoft Access elimina automáticamente la información de bloqueo. archivo cuando el último usuario cierra el archivo de base de datos ".

Por favor, no use Access para una situación de usuario múltiple.

Acabo de pasar por dos semanas de dolor porque mi predecesor en un proyecto eligió Access como un back-end.

Razones concretas:

No hay tal cosa como Linq-to-Access
El acceso tiene numerosas peculiaridades, como dependencias en el orden de adición de parámetros a los comandos que le llevarán una gran cantidad de años para depurar
El acceso no escala
Las actualizaciones de bases de datos son una tarea ardua cuando se compara con el uso de SQL Server

Se supone que el acceso es multiusuario; creo que Microsoft lo recomienda para hasta 4 o 5 usuarios, pero en la práctica recomendaría que nunca uses una base de datos de Access donde hay más de un usuario, aunque si realmente te gusta No tengo elección, es aceptable para dos o tres, dadas ciertas condiciones.

He tenido experiencia de cuatro o cinco sistemas que usan un back-end de base de datos de Access, todos adquiridos de otros ''desarrolladores'', y en todos los casos los he movido a SQL Server como prioridad después de cualquier actualización inmediata y corrección requerida al aceptar el contrato, generalmente tan pronto como pueda hablar con el jefe que paga la factura. El lapso de tiempo para eso suele ser de varios meses, por lo que he visto que se ejecuta simultáneamente durante un período de tiempo razonable en varias aplicaciones diferentes.

En realidad, generalmente funcionará bastante bien si el sistema no tiene muchas inserciones / actualizaciones simultáneas y no se usa mucho. Los principales problemas prácticos en mi experiencia son ...

Es susceptible de corrupción, simplemente lo hace. En general, esto no supone un gran problema, ya que al abrir el archivo y ejecutar el compacto y la reparación se solucionarán los problemas, pero un buen régimen de respaldo es absolutamente esencial.
Es lento. Cada vez que actualicé un sistema a SQL Server, recibí muchas felicitaciones por acelerar el sistema de los usuarios.
El archivo de base de datos se hincha debido a la forma en que Access marca los registros actualizados o eliminados. Esto ralentiza aún más el sistema ya que el archivo debe cargarse en la red. En consecuencia, es esencial algún régimen que comprima los datos, por lo general sobre una base diaria.

Todo lo anterior es un problema mucho menos problemático con los sistemas de usuario único ya que los problemas subyacentes que provocan estos son mucho menos prominentes.

En general, debo enfatizar que nunca recomendaría Access para ningún sistema multiusuario. Sin embargo, si realmente lo has hecho, probablemente te salgas con la tuya siempre que sea una aplicación poco utilizada y establezcas los procedimientos de copia de seguridad y mantenimiento.

Ya se ha dicho varias veces que se usa una verdadera plataforma de base de datos gratuita y multiusuario. Pero una de las razones por las que no se ha declarado. Esta razón es, ¿cuántas bases de datos de acceso existentes, desordenadas, problemáticas y grandes han comenzado como "algunos registros, uno o dos usuarios como máximo"? Me atrevería a decir todos.

A menos que haya solo dos o tres empleados en toda la compañía, las probabilidades son que si desarrolla una pieza de software útil, eventualmente será utilizada por más de los dos o tres usuarios originales, tenga más que los miles de registros originales. , y se expandirá a lo largo de los años para incluir muchas formas, muchas más tablas y muchos más datos. No puedes rehacer la base de una casa una vez que la construyes. Construya una base sólida hoy, y puede expandir la casa al contenido de su corazón. Lo mismo para el software.